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APOLLO EXPERIENCE REPORT 


SIMULATION OF MANNED SPACE FLIGHT FOR CREW TRAINING 

By C. H. Woodling, Stanley Faber, John J. Van Bockel, 
Charles C. Olasky, Wayne K. Williams, 

John L. C. Mire, and James R. Homer 
Manned Spacecraft Center 

SUMMARY 


From the early phases of Project Mercury through the Gemini and Apollo Pro- 
grams, flight simulators have been the key elements in the astronaut training programs. 
As the missions progressed in complexity, the sophistication, number, and variety of 
simulators employed for astronaut training were increased correspondingly. Through 
space -flight experience and evolution of the simulators to meet associated training re- 
quirements, several factors have been established as critical and basic for providing 
adequate flight simulators for crew training. Included in these factors are high-fidelity 
crew stations, especially in the area of controls and displays; accurate simulation of 
the spacecraft systems, including the guidance computer and navigation system; com- 
plete visual display systems for simulated out-the -window scenes; and certain moving- 
base simulators for high-fidelity training in particular portions of the missions. The 
significance of these factors for new programs will depend to a large degree on the mis- 
sion objectives and requirements. Nevertheless, flight simulators incorporating some 
of these items in their design and operation will be vital in future astronaut training 
programs. 


INTRODUCTION 


In this report, ’’simulation” refers to the operation of trainers for instructing 
flight crews in the various control and monitoring procedures of manned spacecraft. 

The purpose of simulation for crew training is high-fidelity duplication of a wide range 
of inflight conditions and variables to obtain precise flight crew response to sophisti- 
cated and critical mission events. Repeated simulation exposure allows the crew to 
become proficient in interfacing with the flight hardware and ground -support elements, 
thus enhancing mission success and safety. In this context, a simulator is defined as 
a complex set of hardware (including computers, visual display systems, and simulated 
crew stations) that presents, with a high degree of accuracy, the total flight character- 
istics of the actual spacecraft and mission. Excluded from this classification are train- 
ers that are full-scale spacecraft mockups designed primarily to refine crew tasks 
related to the handling of equipment in performing such activities as stowage, ingress 
and egress, maneuvering in zero-g and l/6-g (lunar surface) conditions, handling 



photographic equipment, and general housekeeping within the constraints imposed by 
flight hardware and the space-flight environment. Although the remainder of this paper 
is concerned primarily with simulators, it is only proper to give recognition to these 
mockups that played such a significant and necessary role in complementing the simu- 
lator training for all major mission phases. A typical example was the extensive train- 
ing program carried out for the Apollo lunar landing mission using full-scale mockups 
of the lunar module (LM) for lunar-surface training and of the command and service 
module (CSM) for ingress and egress and scientific instrument module training. 

The topics of this report include some of the more significant aspects of space- 
flight simulation: crew-station fidelity, visual display requirements, moving-base sim- 
ulations, and configuration management. The various topics relate primarily the 
experience gained in these areas of simulation since the beginning of manned space 
flight. It is hoped that future programs might benefit through discussion of this 
experience. 

Credit for the separate sections of this report is given to those who, through their 
direct involvement with manned -space -flight simulation and training, were able to re- 
port firsthand the data contained herein. These individuals and their respective sections 
are as follows: C. H. Woodling and John J. Van Bockel, background and discussion; 
James R. Homer and John L. C. Mire, crew-station fidelity; Stanley Faber, visual 
display requirements; Wayne K. Williams, moving-base simulations; Charles C. Olasky, 
simulator configuration management; and C. H. Woodling, overall compilation and 
editing. 


BACKGROUND 


It is pertinent to preface these discussions with a listing of the crew simulators 
employed in support of manned space flight, to note the simulator use for training during 
each of the flight programs, and to discuss briefly the history of simulators from the 
beginning of Project Mercury. 

The crew-training simulators used for Project Mercury and for the Gemini and 
Apollo Programs are listed in table I. These simulators are described in the appendix. 
The crew-training use of the various simulators throughout the flight program is pre- 
sented in tables II and III. During Project Mercury and the Gemini and Apollo Pro- 
grams, each crewman (on an average) spent one -third or more of the total training 
program time in simulations (table II). The crews of the lunar landing missions (Apollo 
missions 11 to 15) spent slightly more than 50 percent of their total training time in 
simulator training. In addition to the actual time spent in the various simulators, other 
training activities were accomplished in support of the simulator training. For ex- 
ample, the Apollo crews averaged more than 150 hours of systems briefings as a pre- 
requisite to simulator training. 

A breakdown of the simulator use by program and simulation facility is presented 
in table III. Progressing from Project Mercury through the Gemini Program to the 
Apollo Program, the number and complexity of the simulators increased. Also, it is 
interesting to note the increased emphasis on the mission simulators. The 708 hours 
spent by the crews in the Project Mercury procedures trainers represent 
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approximately 53 percent of the total simulation time of 1330 hours. In the Gemini 
Program, the hours logged in the mission simulators are 67 percent of the total; and, 
in the Apollo Program, the command module simulator (CMS) and lunar module simu- 
lator (LMS) hours combined are 80 percent of the total of 29 967 hours spent in all 
Apollo simulations. 


TABLE I. - FLIGHT CREW SIMULATORS 


Simulator 

Purpose 

Mercury j 

Mercury procedures simulator (2) 

Primary spacecraft and mission simulator 

Centrifuge (Naval Air Development Center, 
Johns ville, Pa.) 

Moving-base simulator for launch, launch abort, 
and entry with associated acceleration 
environment 

Air- lubricated free -attitude trainer 

Moving -base simulator for multiple -axis pilot 
control tasks such as on -orbit attitude control, 
retrofire, and entry 

Part-task trainer (2) 

Retrofire and entry part -task training 

Gemini 

Gemini mission simulator (2) 

Primary spacecraft and mission simulator 

Dynamic crew procedures simulator 

Moving -base simulator for launch, launch abort, 
and entry 

Translation and docking simulator 

Moving-base simulator for formation flying and 
docking 

Centrifuge (Naval Air Development Center, 
Johnsville, Pa.) 

Moving-base simulator for launch, launch abort, 
and entry with associated acceleration 
environment 

Apollo 

Command module simulator (3) 

Primary CSM mission simulator 

Lunar module simulator (2) 

Primary LM mission simulator 

Command module procedures simulator 

Part-task procedures simulator for CSM 
rendezvous 

Lunar module procedures simulator 

Part-task procedures simulator for LM lunar 
descent and ascent including rendezvous 

Dynamic crew procedures simulator 

Moving -base simulator for launch, launch aborts, 
and entry 

Translation and docking simulator 

Moving-base simulator for LM -active formation 
flying and docking 

Centrifuge (NASA Manned Spacecraft Center) 

Moving -base simulator for launch, launch abort, 
and entry with associated acceleration 
environment 

Lunar landing training vehicle (LLTV) 

Free -flight training vehicle for final phase of lunar 
landing 

Lunar landing training vehicle simulator 

Familiarization with LLTV systems 

Langley lunar landing research facility 

Dynamic simulator (tethered) for final phase of 
lunar landing 

Partial-gravity simulator (2) 

Dynamic simulator for training in the 1/6 -g lunar - 
surface environment 
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TABLE n. - SIMULATOR TRAINING SUMMARY 



Number of 
crewmen 

Simulator 
time, hr 
(a) 

Simulator time 
per crewman 
(average), hr 

Total training 
program time, hr 

Simulator portion 
of total training 
program time, 
percent 

Mercury 

7 

1 330 

190 

4 038 

33 

Gemini 

20 

6 964 

348 

17 991 

39 

Apollo (through 
mission 15) 

32 

29 967 

936 

69 248 

43 

Total 

59 

38 261 

- 

91 277 

42 


a 

Exclusive of simulator prebriefings and postbriefings. 


TABLE ni. - SIMULATOR USE FOR FLIGHT CREW TRAINING 



Time per program, hr 


Simulator 

Mercury 

Gemini 

Apollo 
(through 
mission 15) 

Total 
time, hr 

Mercury procedures simulator (2) 

708 

- 

-- 

708 

Air -lubricated free -attitude trainer 

82 

- 

*- 

82 

Multiple -axis spin test inertial facility 

27 

- 

- 

27 

Part -task trainer (2) 

175 

- 

- 

175 

Centrifuge 

338 

100 

58 

496 

Gemini mission simulator (2) 

- 

4682 

- 

4 682 

Dynamic crew procedures simulator 

-- 

428 

557 

985 

Translation and docking simulator 

~ 

276 

64 

340 

Part -task trainer 

- 

61 

- 

61 

Rendezvous simulator 

- 

1417 

~ 

1 417 

Command module simulator (3) 

- 


14 584 

14 584 

Lunar module simulator (2) 

- 

- 

10 672 

10 672 

Command module procedures simulator 

- 

- 

1 008 

1 008 

Lunar module procedures simulator 

- 

! 

753 

753 

Lunar landing training vehicle and 
simulator, lunar landing research 

- 

- 

949 

949 

facility 4 





Manned Spacecraft Center mission 
evaluators 


~ 

146 

146 

Translation and docking simulator 
(Langley Research Center) 

- 

- 

87 

87 

Contractor mission evaluators 


- 

859 

859 

Massachusetts Institute of Technology 
evaluators (2) 

- 

- 

56 

56 

Full-mission engineering simulator 

- 

- 

174 

174 

Simulator prebriefing and postbriefing 

b 175 

b 465 

b 703 

b l 343 

Partial -gravity simulator, mobile 
partial-gravity simulator 

— 

b 93 

b 27 

b 120 

Total 

1330 

6964 

29 967 

38 261 


a Time computed on the basis of 2 hours logged for each LLTV flight. 
b Not included in total simulator hours. 
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Classification 



Figure 3.- Command module simulator. Figure 4.- Lunar module simulator . 


Simulators can be grouped into several classifications. For the purpose of this 
report, the following definitions will apply. 


Full-mission simulator. - A full-mission simulator is a device in which all crew- 
related phases of the mission are consolidated into one complex. Included in this cate- 
gory are the Mercury procedures simulator (MPS) (fig. 1), the Gemini mission 
simulator (GMS) (fig. 2), the CMS (fig. 3), and the LMS (fig. 4). 
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Part-task simulator . - A part-task simulator is a device in which only a portion 
of the mission or several major crew tasks are simulated. Fidelity in these tasks may 
be greater than that achieved with the mission simulator. 

Moving -base simulator . - A moving-base simulator is a device in which the crew 
station or crewmember (or both) is subjected to some physical motion. This physical 
motion could be intended to give the pilot realistic cues of acceleration, velocity, or 
position or could be an undesirable artifact of the simulation technique. One example 
of a part-task and moving-base simulator is the LLTV (fig. 5), which provides a high- 
fidelity, six-degree-of-freedom duplication of the final lunar descent from an altitude 
of approximately 500 feet to touchdown. 



Fixed-base simulator . - A fixed -base 
simulator is a device in which no physical 
motion is transmitted either to the crew sta- 
tion or to the pilot. All the dynamics of the 
simulation are provided through displays on 
the crew-station panels and by movement of 
out-the -window scenes. 


The value of high-fidelity simulation 
was well known through aircraft flight ex- 
perience before Project Mercury. The de- 
pendence on simulation for space mission 
success and crew safety generally is greater 
than the dependence on simulation for air- 
craft testing because of the natures of the 
two flight programs. Space-flight crews 
are fully committed at lift-off to an entire 
mission, in which a broad envelope of opera- 
tional variables is exercised. Aircraft test 
research usually allows for a more gradual 
exercising of the total flight envelope 
through a series of "buildup” flights. 

Whereas the aircraft test pilot can obtain 
much of his training coincident with actual 
Figure 5.- Lunar landing training flight testing, the crews for space missions 
vehicle . must receive all their training and be highly 

proficient in all flight tasks before the mis- 
sion. Primarily for this reason, the space - 
flight simulators require the highest degree of fidelity of spacecraft and mission 
simulation. Aircraft experience was used extensively in the development and operation 
of the first space-flight simulator, the MPS. For the follow-on space programs, 

Gemini and Apollo, the major developmental impetus for the simulators was derived 
from space program experience. 


Discussion 


Early in Project Mercury, the effect of space -flight environmental factors upon 
crew performance caused considerable concern. Consequently, training emphasized 
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crew exposure to such conditions as high acceleration forces, zero-g conditions, heat, 
noise, and spacecraft tumbling motion. The Mercury astronauts received many train- 
ing exercises in an attempt to duplicate these environmental conditions. Particular 
concern was expressed about crew capability to manually control the spacecraft during 
the high acceleration loads imposed during launch and entry. As a result, the Mercury 
astronauts participated in four centrifuge programs at the Naval Air Development Cen- 
ter, Johnsville, Pennsylvania. Project Mercury flight results verified that the condi- 
tions of space flight had no adverse effects on crew performance for missions as long 
as 22 hours in duration. Consequently, crew-training programs for the Gemini and 
Apollo missions deemphasized such considerations and concentrated to a great extent 
on the many and complex operational considerations. Project Mercury experience did 
point out the importance of simulating out-the -window scenes, which became even more 
important for the Gemini and Apollo missions. The Mercury simulators did not have 
adequate out -the -window displays, and a major effort to remedy this situation for the 
Gemini simulators was begun. 

The value of high-fidelity simulators was verified throughout Project Mercury, 
thus establishing for the Gemini and Apollo Programs the requirement for a full- 
mission-simulator inventory both at the NASA Manned Spacecraft Center (MSC) and at 
the NASA John F. Kennedy Space Center (KSC) launch site. Operation of simulators at 
KSC was deemed necessary primarily because of crew participation in specific checkout 
tests of the spacecraft and launch vehicle at the launch site. 

For each Mercury flight, full dress rehearsals (referred to as simulated network 
simulations) of the most significant flight phases integrating the crew, the flight plan, 
and the ground -support elements were accomplished as part of the preflight prepara- 
tions. These simulations proved to be extremely valuable for the flight and ground 
crews and, consequently, were further developed and expanded for the Gemini and 
Apollo Programs. A simulated network simulation for the Apollo lunar landing mission 
involving the LMS and CMS tied in with the Mission Control Center (MCC) in Houston, 
Texas, required the precise coordination and synchronization of 10 large-scale digital 
computers. The magnitude of this phase of the simulation training program is indicated 
in table IV in terms of the number of days spent running full-mission simulations during 
the Gemini and Apollo Programs. 

The Gemini Program required more sophisticated simulators than did Project 
Mercury, principally because of the Gemini rendezvous mission objective. Crew capa- 
bility to effect the rendezvous by using primarily out-the -window information was essen- 
tial to the mission and dictated that an elaborate visual system be incorporated into the 
Gemini mission simulators. The development and use of an advanced state-of-the-art 
infinity optical display system added considerably to the realism and value of simulator 
training for the Gemini crews. 

Results of the Gemini Program indicated quite clearly that a well-defined and ef- 
fective configuration management system was needed to maintain the simulators in a 
configuration that corresponded closely with the continuously changing spacecraft. 
Basically, this meant a quick- response system operated by personnel cognizant of all 
spacecraft changes and capable of deciding on and contracting for the necessary modi- 
fications and incorporating these into the various simulators. A configuration control 
panel committee, with ancillary working groups, was formed for the Gemini and Apollo 
Programs with good results. 
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TABLE IV. - SIMULATED NETWORK SIMULATIONS 3, 
(a) Gemini Program 


Mission 

Simulation sessions, days 

III 

4 

IV 

7 

V 

7 

VI 

13 

VII/VI 

9 

VIII 

9 

IX 

- 9 

X 

7 

XI 

6 

XII 

7 


(b) Apollo Program 


Mission 

Simulation sessions, days 

CMS/MCC 

LMS/MCC 

CMS/LMS/MCC 

Total 

7 

18 

0 

0 

18 

8 

14 

0 

0 

14 

9 

10 

2 

8 

20 

10 

11 

0 

7 

18 

11 

7 

4 

7 

18 

12 

10 

3 

12 

25 

13 

13 

5 

9 

27 

14 

15 

7 

13 

35 

15 

19 

5 

! 

7 

31 


cl 

This summary includes only the mission simulations involving the use of mis- 
sion simulators with flight crews and does not include the many more additional days 
of "math model" simulations (without the mission simulators) for flight controller 
training. 


Forecasts of the simulator training requirements for the Apollo Program showed 
that a large inventory of various types (full mission, part task, moving base) of stra- 
tegically located simulators would be needed. The Apollo Program imposed severe 
schedule and simulator -complexity constraints; a requirement was dictated to train a 
large number of three -man crews within a relatively short time in sophisticated and 
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critical mission simulators (three command module simulators and two lunar module 
simulators) with complete visual systems. The capability for integral operation of the 
simulators with each other and with the MCC in Houston also was required. The greatei 
number of command module simulators was needed to accommodate the greater number 
of command- module-only flights that comprised early program concepts. In addition, 
certain special-purpose part-task simulators were considered necessary to provide 
supplementary training, to afford overall training flexibility, and to support the crew 
procedures development effort (an integral part of crew training). Among these special- 
purpose simulators were the command module procedures simulator (CMPS) (fig. 6), 
the lunar module procedures simulator (LMPS) (fig. 7), the Apollo translation and dock- 
ing simulator (TDS) (fig. 8), and the Apollo dynamic crew procedures simulator (DCPS) 
(fig. 9). Perhaps the most notable special-purpose simulator was the LLTV. Because 
of the limitations of accurately simulating this critical phase of the lunar mission on 
ground-based simulators, the free-flying LLTV was employed to provide an extremely 
realistic dynamic simulation of the lunar approach and touchdown. 


Concerning the simulators themselves, several basic decisions were made to 
satisfy the fidelity requirements. One of these decisions was that all spacecraft sub- 
systems would be simulated by the com- 


puters; that is, no actual (hardware) space- 
craft subsystems would be used. One area 
handled in a special way was simulation of 
the Apollo onboard guidance and navigation 
computer. The simulation successfully 
used was based on an "interpreter” concept 



Figure 6.- Command module procedures 
simulator . 



Figure 7. - Lunar module procedures 
simulator. 
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Figure 8. - Translation and docking 
simulator (Apollo). 


in which a general-purpose digital com- 
puter was programed to accept the same 
program as the flight computer and to re- 
spond to spacecraft systems precisely as 
the flight computer would. The interpre- 
ter superseded a barely adequate, costly, 
and always late functional approach for 
simulation of the onboard computer. 



Figure 9.- Dynamic crew procedures 
simulator (Apollo). 


Another area that required considerable updating and redesign was the difficult 
visual simulation of the lunar landing. As will be discussed in the section on visual 
display simulation, the initial concept of the LMS fell short of the realism required. 

An intensive development effort was undertaken to improve the visual simulation for the 
lunar landing and at the same time to permit timely use of the LMS for the early orbital 
training. This effort was successfully concluded to provide high-fidelity landing and 
ascent training for the first lunar landing and subsequent flights. 


Although the remainder of this report is oriented toward the difficulties and ex- 
perience gained through the operation of the simulator hardware, it by no means implies 
a lesser importance of the software systems. Indeed, a large percentage of the overall 
simulation effort throughout all flight programs was associated with the simulation soft- 
ware. For example, the Apollo lunar landing mission simulation for the CMS consisted 
of 750 000 words of memory residing in four large digital computers. Similarly, the 
LM simulation in the LMS required 600 000 words in three digital computers. At the 
peak of preparation for the first lunar landing mission, approximately 175 support con- 
tractor personnel were assigned to the development and control of the software systems 
of three command module simulators and two lunar module simulators. Another 
200 contractor personnel were assigned to the hardware operations and maintenance. 
Simulator changes required to keep pace with the changing spacecraft and mission num- 
bered more than 30 per month in this same time frame. Configuration management of 
these hardware and software systems is discussed in the section entitled "Simulator 
Configuration Management." 
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CREW-STATION FIDELITY 


Various considerations for the design of the simulator crew station are described 
in this section. The Mercury, Gemini, and Apollo simulator crew stations, particu- 
larly those for the mission simulators, were designed and constructed with a high de- 
gree of fidelity to simulate closely both spacecraft performance and interior appearance. 


Controls and Displays 

The controls and display panels provide the necessary interface between the crew 
and the spacecraft. Only through the medium of properly designed panels and functional 
integration with simulated systems software can the training be performed efficiently 
i and adequately. The controls are used to provide intelligence to the supporting com- 
puters in the form of analog voltage or discrete signal inputs. To meet crew-training 
j requirements, it becomes necessary to simulate all known characteristics of a control 
switch, such as lock and spring-loaded positions, as well as the forces required to 
change positions. Commercial switches that look and operate like flight units usually 
can be procured at a fraction of the cost of the spacecraft hardware. Valves to control 
■ the flow of fluids in the actual spacecraft usually are not required in an electrically sen- 
| sitive simulator. Basically, two types of valve operations require simulation. The 
j type of valve required for adjusting the flow of a fluid is referred to as a proportional- 
flow valve, and the discrete detent-hold operation uses a shifting-port type of valve. 

The function of the proportional-flow valve is simulated by the attachment of a potentiom- 
eter to the control shaft for position sensing. Switch activation by cam and detents is 
used to simulate shifting -port valve action. The torque force profile can be simulated 
accurately by placing a frictional, adjustable sleeve around the shaft being turned. 

When crew training requires a close duplication of hardware operating character- 
istics, the use of flight-configured hardware has provided the best results. Such com- 
ponents as hand controllers must duplicate as nearly as possible force profiles, dead 
bands, feel of multiple detents (soft stops), handle free-return characteristics, mechan- 
ical damping, and signal generation for both discrete and proportional displacement. 

A wide range of commercial variable controls (such as potentiometers) that have 
characteristics acceptable for use without modification are available to simulate equiv- 
alent flight hardware. However, specialized assemblies consisting of a transformer 
element and a potentiometer or a rheostat (both of which may have certain characteris- 
tic profiles to interface delicately with an instrument or system in a balanced relation- 
ship) would be difficult to obtain unless procured from the manufacturer of the flight 
article. Such units usually are procured for the simulators without the flight qualifica- 
i tion test necessary for spacecraft hardware, thereby reducing the cost of the units and 
shortening procurement time. Circuit breakers also require some special considera- 
tion. In simulating wiring malfunctions (resulting in high current flows) that trip re- 
I spective circuit breakers, it is not practical to use spacecraft hardware that trips at 

! relatively high currents (e.g. , 100 amperes). Instead, a standardized low current 

(0.01 ampere on a 26-volt dc system) circuit breaker has been used throughout the 
simulators. 
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Stowage 


Since the early Mercury flights, the proper location of onboard data and loose 
equipment has been a necessary inflight task and, therefore, a training requirement. 
The need for assigning every item a specific stowage location and the procedure for 
handling loose items could not be neglected. Ideally, flight-type equipment for stowage 
training is preferred. However, because of the disadvantages of the high cost of the 
equipment and the frequent handling under one-g conditions, actual flight equipment is 
seldom used for simulator stowage. For training purposes, a nonflight item serves as 
well if it functionally fulfills the intended use. 


Lighting 

Lighting of the crew compartment was not considered critical in terms of intensi- 
ties and spectrum composition. Experience has shown that light levels sufficient for 
general illumination are satisfactory as long as the simulated intensity does not deviate 
appreciably (±20 percent) from the actual. 

Because of the use of optical eyepieces (telescope and sextant) for navigational 
sighting in the Apollo spacecraft, the floodlight intensity settings were usually low, 
which caused some difficulty in reading the meters. As a consequence, all simulator 
meters were lighted integrally, and panel nomenclature was blacklighted with electro- 
luminescent elements, as in the spacecraft. 


Aural Cues 

Audible cues are simulated and presented to the flight crews whenever applicable 
during the training exercise. On the Apollo mission simulators (CMS and LMS), such 
cues as booster thrust, cabin decompression, and the firing of pyrotechnic devices and 
attitude -control jets are simulated. Noise levels in the communication channels as well 
as ambient noise are simulated and transmitted to the flight crews through headsets and 
through concealed loudspeakers within the crew stations. 

Aural cues are generated by various means, such as a low-frequency reverbera- 
tion that feeds into a summing amplifier. The signal output (simulated aural cue) of the 
summing amplifier then is fed through a voltage-controlled attenuator to a summing am- 
plifier and then to the loudspeaker in the mission simulator cockpit. The instructor at 
his station is included in this loop to enable him to control the amplitude of the sound 
manually with a decibel-control potentiometer. 


Markings and Nomenclature 

All controls and displays, stowage areas, and other hardware must be properly 
marked with the same nomenclature used in the flight spacecraft. Nomenclature is 
especially important during the early phases of crew training to aid in system opera- 
tions. However, in time, the crewmembers rarely resort to reading nomenclature be- 
cause they become so familiar with the location and function of each control or display 
that reading is unnecessary. 
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Space Suit and Cabin Environment Requirement 

In the various simulators, suited operation throughout all phases of flight, yet 
with the capability for the crew to train unsuited for comfort, has been emphasized. 

The crew- station environment is maintained at ambient pressure with circulated, 
temperature -regulated air. All the controls for the crew-station environment are man- 
ual, and the systems are purely simulator oriented. The crew-station-environment 
parameters of temperature, humidity, and noise level are electrically monitored at the 
instructor-operator station. The crew-station cabin-temperature and cabin-pressure 
meters display simulated values in accordance with the flight profile; that is, while on 
the launch pad, the simulated cabin pressure is 14.5 psi and decreases proportionately 
during launch, settling at 5.0 psi for orbit conditions. 

A realistic simulation of suited conditions is provided. The use of fully pressur- 
ized suits provides the proper constraints for controlling the simulator with rigid-suit 
conditions. Great care always has been taken to prevent the possibility of a rapid pres- 
sure buildup in the simulator suit loops. The CMS suit loop has a motor-driven pres- 
sure control that varies the airflow at a fixed rate of 2 psi/min, reaching 3.75 psig for 
hard-suit and 0.25 psig for soft-suit conditions with constant airflows under either man- 
ual or automatic (computer) control. 


Crew Couches 

Exact replicas of the crew couches have been used in the simulators to provide 
proper body restraint, correct reach patterns, and accurate couch- manipulation 
capability. 


Crew-Station Hardware 

Simulator crew-station hardware is discussed in two categories: contractor- 
furnished equipment (CFE) and Government-furnished equipment (GFE). 

Contractor-furnished equipment . - The contractor in this case usually was the 
prime spacecraft contractor. The spacecraft contractor has several avenues open to 
provide hardware for the simulators. If it is not practicable to simulate the spacecraft 
components, actual spacecraft hardware is supplied. Such components as attitude con- 
troller assemblies, thrust and translation controller assemblies, attitude indicators, 
and polycarbonate cover assemblies are examples of actual spacecraft items procured 
directly from the prime contractor. Much of the CFE for the simulators is manufac- 
tured on the production line at the same time the spacecraft parts are fabricated. Sim- 
ulator parts made in this manner are identical to spacecraft hardware. 

In many cases, simulator parts do not require the sophisticated design or the 
rigid tolerances demanded for the spacecraft. The frequent use of rejected spacecraft 
parts on the simulators results in cost savings. During the Apollo Program, the space- 
craft contractor maintained another manufacturing capability commonly referred to as 
the '’model” shop. The personnel in this shop usually work from engineering design 
sketches to fabricate prototype units for spacecraft qualification tests. The model shop 
is often used to fabricate simulator hardware. Components made in this shop for the 
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simulators do not have to meet the stringent spacecraft specifications. Occasionally, 
hardware for the simulators is made from initial design sketches to meet the desired 
leadtime necessary to support crew-training exercises. Various other contractor 
sources of simulator hardware are available, including the simulator manufacturer. 

Government -furnished equipment . - Simulator parts can be made at MSC. This 
source of fabricated hardware is generally the preferred route, on a cost basis. Fed- 
eral stock provides a prime source for standard off-the-shelf items for installation and 
maintenance work. 

A substantial amount of loose hardware is provided to the spacecraft simulator as 
GFE. Optical sights, suit hoses, backpacks, and most of the stowed items are pro- 
vided by the supplying organization at MSC . Some units are included in the simulators 
on a permanent basis, but other units are furnished by the suppliers as required for the 
training exercises. Other hardware, such as hand controllers and attitude indicators, 
is provided for the simulators by the contractors who supply these items for the 
spacecraft. 


Concluding Remarks 

A high degree of crew-station fidelity, particularly in the full-mission simulators, 
is necessary for accurate simulation of spacecraft performance and mission character- 
istics. In addition to a complete simulation of the spacecraft controls and displays, 
such items as stowage provisions, lighting, aural cues, and crew hardware are ex- 
tremely important in providing this required fidelity. 


VISUAL DISPLAY SIMULATION 


Early in the evolution of manned space flight, the requirement for a window in the 
spacecraft was identified. Although the window served several purposes, the most im- 
portant was as a backup attitude reference. Experience in aircraft control tasks and 
during early space flight had established that training was necessary to enable the crew- 
member to correlate his out-the -window references with his instruments. The various 
techniques used to produce the simulated out-the -window scenes throughout Project 
Mercury and the Gemini and Apollo Programs are described in this section. 


Display System 

The first element of a visual simulation system is the display system, the element 
into which an image is projected for viewing by the crew. The determining factors of 
this element are the apparent distance to the image being viewed and the field of view 
(FOV) of the window. A general requirement is that all images appear at infinity as 
they do in reality. For docking, the simulation requirement was that the image appear 
to approach the crewmember as in the actual situation. Field-of-view requirements 
were based on the particular spacecraft window being simulated, with some allowance 
for pilot eye or head movement. The Mercury spacecraft requirement was a 60° FOV, 
although that of the Apollo LM (the largest requirement) was a 110° FOV as measured 
at the eye. 


14 


All mission simulators used an infinity display system. Figure 10 is a schematic 
of a typical window system using reflective optics techniques. To satisfy the docking 
display requirement, the display or output tube was moved from its infinity position. 
Approximately 4 inches of movement of the display tube made the image appear to move 
from infinity to 8 feet from the viewer. 


Figure 10. - Typical reflective infinity 
display system. 



The infinity image system has the 
desirable characteristic that, as the crew- 
man moves his head, the item being viewed 
appears to move correctly. Conversely, 
because of parallax, viewer head motion 
grossly affects what is seen with direct- 
view, screen-type systems; therefore, the 
viewer must hold his head relatively still 
to resolve properly the source of the ob- 
served motion. 

Specifications for the FOV could not 
have been met without some design com- 
promises. In the Mercury and Gemini sim- 
ulators, the FOV requirements (60° and 
88°, respectively) for completely filled win- 
dow scenes were met as long as the pilot 
maintained his eyes within an area defined 
as the exit pupil. This was not a severe 
constraint in these simulators, because of 
the relatively limited head freedom. In the 
CMS, location of the exit pupil at the window 
allowed unlimited viewing except as con- 
strained by the physical characteristics 
of the spacecraft. The design FOV was 90°. 
The exit pupil for the side windows was not 


quite as large as the windows; however, the small dark bands outside the exit pupil 
were hardly noticeable and were not a serious problem. 

In the LMS, the large FOV, coupled with a large window (17 by 22 inches to ex- 
treme apexes) and almost total freedom of the crewman to position his head, required 
the greatest compromise. The first compromise was to place the exit pupil in the area 
of the crewman’s design eyepoint (i.e. , the normal eye position). From this design 
eyepoint, the crewman could move approximately 4 inches in any direction with no loss 
of display. The second compromise was to point the axis of the forward -window display 
down to feature the land ing scene at the expense of the upward scene. In the actual 
spacecraft, the crewman can look up approximately 20° from the design eyepoint, and 
even more by hunching down. In the simulator, the crewman was limited to less than 
10°. Even with this compromise, the bottom apex of the LM window was blank as 
viewed from forward eyepoints. Because these adjustments were chosen very carefully 
against anticipated use of the window, the limitations have had no adverse effect on 
training. 
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The infinity display systems used with the mission simulators produced the de- 
sired effects as long as proper consideration was given to mission simulation require- 
ments. These systems did have some drawbacks. Relatively high cost (30 to 40 percent 
of total mission simulator cost), large physical sizes, ghost images, extremely low 
light transmission, and backlight scatter were the most significant. Since the initial 
application of the infinity optics technique to simulation, additional development has re- 
sulted in reductions of cost and size. These new systems are of both refractive and 
reflective types. The refractive types tend to be brighter, although with some loss in 
image quality, than the reflective types. 


Celestial Simulation 

Simulation of the stars was predicted on both navigational and attitude -reference 
requirements. In orbital flight, these requirements are intermixed because the pilot 
must know his location to use the stars as an attitude reference . In simulation of the 
star field, consideration was given to the number and relative brightness of the stars 
selected and to the static and dynamic accuracies required. The number of stars chosen 
for all projects to date is approximately 1000, consisting of all those brighter than a 
+5 magnitude. The logic of selecting this number was that the navigation stars and the 
constellations used for identifying them are all brighter than the fifth magnitude. One 
other factor in this selection was that fifth magnitude stars are the dimmest generally 
visible to the unaided eye from the ground. 

In training crews for constellation recognition, variations in brightness, at least 
to the whole magnitude, must be simulated. The specifications required at least seven 
discrete levels (+5 to -1), with correct relative brightness between levels desirable but 
not mandatory. The specifications also required that this variation be in the true 
brightness of the star, not as produced by merely increasing light-source sizes. 

Static positional accuracy specifications were dictated by the need to identify con- 
stellations. It was determined that the appearance of constellations changes signifi- 
cantly with even minor positional errors. Furthermore, if the stars were to be used 
in a navigational task, an instrument such as a sextant would be necessary and an accu- 
racy compatible with the instrument was required. To reduce cost, star positional re- 
quirements were moderated to 1 milliradian (approximately 0.06°) for all navigation 
stars and 0.5° for all other stars. Specifications also required that if the constellation 
appeared incorrect with a 0. 5° error in a given star location, the positional accuracy 
for that star must be tightened to that of the navigation star. 

The specified dynamic positional accuracy also required compromise, as the re- 
quirement was complicated by the large range of vehicle angular motions possible in a 
spacecraft. Pilot-controlled rates range up to 20 deg/sec, with uncontrolled vehicle 
angular rates of 50 to 60 deg/sec possible. Although a perfectly stationary spacecraft 
is not possible, rates can be as low as 0. 1 deg/min for small spacecraft motions. 

From his stable and vibrationless viewing position, the crewman could detect such small 
motion. The final specifications derived for all spacecraft simulation programs re- 
quired as smooth a low- speed drive as could be produced and permitted lags in position 
at angular rates above 15 deg/sec. Stepping motions that were detectable by the crew- 
members were deemed unacceptable. 
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In all simulators, the same basic technique was used to produce the star displays. 
Approximately 1000 individual stars were simulated by small, highly reflective steel 
balls set into the surface of a (celestial) sphere. When the highly polished balls were 
illuminated by a point source of light, they reflected the point of light, the relative 
brightness being a function of the size and coating of the tails. Balls as small as 
0. 1 inch and as large as 0. 8 inch in diameter have been used. Mirror surfaces concen- 
tric with the celestial sphere were used to keep the individual balls in focus over the 
FOV of the window. This technique produced excellent representations of the star 
field. The only anomaly noted on the display was a halo created by some of the coated 
balls. Unfortunately, in the LMS the halo stars were all navigation stars, and the halo 
made recognition relatively easy. Therefore, the use of coatings to simulate various 
magnitudes is not recommended. 

A chronic difficulty in the simulation of stars was in the dynamic drives of the 
celestial spheres. Smooth, stepless servomechanism drives that hold positional cali- 
brations have not been obtainable, and only continuous maintenance and adjustment have 
produced acceptable operation. This problem has not been limited to the servos and 
torque motors but has been noted in the entire chain, from the equations of motion, 
through the digital conversion equipment, to the spheres. The problem has become 
more acute with each new program, because the range of dynamic motion produced by 
crew action and under crew control has increased from approximately 10 deg/sec for 
the Mercury spacecraft to approximately 20 deg/sec for the LM. Although, in the past, 
continual maintenance and frequent calibration have tended to minimize the impact of 
the servomechanism problems, additional research in product improvement as well as 
improved mathematical and computational techniques should be continued. 

In addition to the window and the unity-power telescope, the command module (CM) 
required simulation of a 28-power, 2° FOV sextant. This optical instrument directly 
interfaced with the onboard guidance computer for navigational procedures. The re- 
quirement for the sextant simulation was to produce the Apollo navigation stars (56 in 
number) with correct background stars, as well as to provide earth or moon limb at 
various altitudes. Static accuracies were the same as specified for the spacecraft, 
that is, 10 arc seconds. The dynamic accuracy requirements of the sextant simulation 
were not high, because all tracking and marking tasks were performed at very low scene 
dynamic rates. The sextant simulation was produced by using a single extremely accu- 
rately positioned navigation star in one optical leg and a selection of as many as 
90 slides of star fields, limbs, and landmarks in a second leg. A pattern generator 
and filters were used to produce the background fields for the navigation star. Pairs 
of rhombic prisms were used to produce the motions in both legs. The two legs were 
combined into a single image by a beamsplitter assembly. For most Apollo training, 
five slides covering the most-used navigation stars were used in the second leg. In 
operation, if either leg were more than 1° off the intended line of sight, the sextant 
simulation was turned off. 

Difficulties encountered in the sextant simulation were similar to those with the 
celestial sphere. That is, producing smooth motion at the extremely low rate used in 
taking navigation marks was not always obtainable in the simulator operation. Another 
difficulty was encountered with the initial simulator design requirement for updating the 
background field. Various changes in the Apollo navigation stars occurred since the 
beginning of the program. The method of generation of background stars made it too 
expensive to update to new background star fields, and the background -star generator 
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was not used. As a result, it was not possible for the crewmember to identify the par- 
ticular navigation star in the sextant. Fortunately, this turned out to be only a minor 
limitation. The accuracy and stability of the actual spacecraft guidance, navigation, 
and stabilization systems were quite good, and the inflight procedures were developed 
to make most effective use of this spacecraft capability. That is, the spacecraft crew- 
member was not required to identify a navigation star with the sextant, because his on- 
board guidance computer programs ensured that the navigation star was always within 
0.5° of predicted value. 


Far Bodies 

For the purpose of this discussion, far bodies are identified as the distant moon, 
earth, sun, and planets, that is, all those bodies in the solar system that subtend an 
angle of approximately 0.5° from the viewpoint. These far bodies were simulated for 
navigational reference and for added realism. In the Apollo simulation program, they 
were deemed important enough to be included. For the sun, the specifications were for 
position, size, and high relative brightness in the windows when the individual window 
was pointed toward the sun. The requirements for distant earth and moon were for po- 
sition, brightness compatible with star simulation, and apparent size change as a func- 
tion of range to each body. In addition, simulation of the sun terminator on the far body 
was desirable. The tolerances on these requirements were not tight. Simulation of the 
larger planets, although desirable for navigational reference, was not mandatory. 

As noted previously, these effects were not included in the Mercury and Gemini 
simulators. In the Gemini simulator, the sun in the window or, rather, the total wash- 
out of the scene caused by the sun in the window was simulated by video flooding the 
television (TV) cathode-ray tube (CRT). 

The sun simulation in the CMS used arc lamps to produce a 0. 5° spot of light in 
each of the windows. Although these lamps did not duplicate the exact sun brightness, 
the simulation was sufficient to wash out the stars and other dim images and served to 
remind the crew to maneuver to some other attitude if they desired to perform any out- 
the -window visual tasks. 

With the LMS, a high level of sun brightness was not required, and the sun was 
simulated by a small disk attached to the celestial sphere. By this means, the desired 
effect was provided at much smaller computation and hardware cost than in the CMS. 

Sun lighting (or sun shafting) in the crew station was not provided in either the CMS or 
the LMS. Although this omission in the simulation has resulted in the crews' using 
spacecraft lights in the simulators that are not normally required in flight, the problem 
has not been a major one. 

The simulation of the distant moon and earth in the Apollo mission simulators also 
fell short of the original specifications. In the CMS, a direct-view film system with 
28 discrete phases of the distant moon was defined. Because these images were too 
small to be reproduced on film, the technique has been abandoned. For most CM simu- 
lation work, the sun simulator was used to represent the distant body. In the LMS, a 
technique similar to the LMS sun simulation was used, but the disk was somewhat less 
reflective than the solar disk. By shaping the disk, the phases of the moon or earth 
also were presented. The distant earth and distant moon were moved or manually 
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adjusted to provide for movement of the distant body relative to the stars, changes in 
sun terminator on the body, and changes in relative size with variation in distance. 

In summary, the far-body simulation requirements have been modified to be con- 
sistent with crew-training needs and state-of-the-art hardware. The requirements for 
far-body simulation from the eyepoint are summarized as follows: 

1. Position tolerance — Tolerance should be ±7° for general realism, ±1° for 
navigational reference. 

2. Size tolerance — Tolerance should be ±0. 25°. 

3. Brightness — Order of relative brightness should be sun, moon, and earth; 
all should appear brighter than the brightest stars. 

4. Phase (solar terminator) — Phase is desirable, but not mandatory. 

5 . Dynamics — Far body should have no apparent motion relative to the star for 
spacecraft-attitude motion simulation. Far body should move with respect to the stars 
for long-term emphemeris effects; however, step changes are acceptable. 

6. Washout and sun shafting — Washout and sun shafting are desirable. 

The CM sextant (previously described) contained a set of slides of the distant 
earth and of the distant moon. These slides reproduced the effect of the terminator on 
the moon for all 28 days of the lunar month and on the earth for those days the CM would 
be in lunar orbit. This slide technique proved acceptable. 


Target Vehicle for Rendezvous 

The target- vehicle simulation was split into two parts: long distance, where the 
tar get -vehicle attitude is not important (e.g. , rendezvous); and short distance, where 
the vehicle attitude in addition to the range becomes important (e. g. , stationkeeping). 
The switchover point was defined as 2 miles, or where the target vehicle would subtend 
an angle less than 0.2°. 

The target vehicle for distant rendezvous does not require attitude information. 
The two requirements are position in the window and relative brightness with range. 

For tracking in darkness, the spot of light was required to blink to simulate a flashing 
beacon. For daylight tracking, the spot should be steady to simulate reflected sunlight. 
Other factors are an accuracy of ±1 ° on position, minimum brightness equivalent to a 
fifth-magnitude star, and a maximum range of 250 miles for the unaided eye. Maximum 
brightness was not specified; however, the intent was to make the minimum-range tar- 
get as bright as possible. The spot of light should be small enough that it does not 
stand out against the background stars unrealistically. 

In all simulators with rendezvous capability, the window simulation was produced 
by electronic techniques on a CRT. This technique met the requirements. The major 
problem was in positional stability of the display. In the. early simulations, frequent 
alinements were required; however, over the span of the Gemini and Apollo Programs, 
improved electronic circuit design has reduced this problem to a minimum. 
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In the Apollo CM, the unity-power telescope and a 28-power sextant were used 
during rendezvous. The simulation requirements for these instruments are similar 
to that of the basic window except for positional accuracy. The telescope was used to 
point the sextant to a specified accuracy of 0.5° relative to the sextant line of sight. 

For compatibility with navigational requirements, the sextant accuracy was specified 
as 30 arc seconds. 

The telescope simulation for distant bodies was a later addition to the original 
simulator. Because of space constraints and the stability problem discussed previously, 
a CRT display was not practical. Instead, the point of light representing the target ve- 
hicle was produced by a simple light bulb. Displacements in the FOV and size were 
produced by mechanical means. 

The CM sextant simulation also was added to the original simulator design. The 
requirement of the distant target was satisfied by using the sextant navigation star sim- 
ulation (described in the paragraphs on celestial simulation) to represent the target- 
vehicle position. The resultant positional accuracy was much better than 30 arc 
seconds. There were two limitations with this sextant simulation. First, with 
28-power magnification, the size, shape, and attitude of the target vehicle were appar- 
ent for relatively long ranges. Second, the omission behind the LM of a lunar back- 
ground made spotting the LM much easier in the simulator than in flight. Of the two 
limitations, the lack of a lunar background was considered more critical. To fully 
simulate the actual situation, a moving scene beneath the CM and behind the LM would 
be required. However, a full simulation is not mandatory. A static scene of the lunar 
disk, or of the lunar limb and terminator, fulfills the minimum requirements. 


Target Vehicle for Stationkeeping and Docking 

At ranges up to 2 miles or when the target vehicle subtends an angle greater than 
0.2°, simulation of the target-vehicle attitude, shape, size, and external features is 
mandatory. The target vehicle should be in proper orientation relative to the active 
spacecraft and should be illuminated in accordance with the relative position of the sun, 
earth, moon, and any lighting source on the active spacecraft. The angular accuracy 
of these vehicle features should be ±2° at ranges beyond 40 feet and ±1° at ranges within 
40 feet. Linear parameters such as size should be accurate to within ±4 percent. Tol- 
erances on lighting functions are large, approximately ±30 percent. All dynamic mo- 
tions should be smooth, with no obvious stepping actions. Additional specifications are 
a proper background behind the target vehicle, with no apparent bleedthrough of stars, 
earth, or moon terrain. 

Two general techniques have been used for target-vehicle simulation: a direct 
analog system of closed -circuit TV and models, and an electronically generated (drawn) 
image. In both systems, the input to the display system was through a CRT in the in- 
finity optics systems. The electronic image generator (EIG) was used successfully in 
one of the Gemini mission simulators, in the Gemini part-task trainer, and in the 
LMPS. In the EIG system, the target vehicle was drawn on the face of the CRT. The 
outline or envelope of the target was drawn at a 60-hertz rate; however, the surface 
was filled in at a 15. 75 -kilohertz rate. The image generation contained nine degrees 
of freedom and produced such phenomena as line-of-sight blanking, illumination 
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shadowing, and perspective distortion. Simple target shapes (cylinders, cones, and 
others) as well as combinations of these shapes were readily simulated with simple 
surface markings and details. 

In the more conventional system such as that used on the Apollo mission simula- 
tors, a scale model of the target was viewed by means of a closed -circuit TV system. 
The model was mounted in a three-gimbal system to reproduce target-vehicle rotations. 
Generally, the innermost gimbals are in the model. The gimbal system should be off- 
set relative to the camera optical axis to avoid gimbal lock at docking attitude. The TV 
cameras or lens systems attached to the TV cameras also are gimbaled in this case to 
represent the active -vehicle rotations. In the CMS, however, rather than camera rota- 
tion, active -vehicle motion was introduced by displacement of the video raster on the 
display CRT. 

The relative range was introduced through a combination of techniques. In all TV 
systems, a track and carriage assembly was used to move the camera away from the 
model. Camera motion produced an apparent model-size reduction. For the Apollo 
CMS and the Gemini mission simulators, this size reduction was supplemented by a 
raster-shrink technique to provide total changes in range. Raster shrink of 67 to 1 was 
successfully used in the CMS. The LMS used two models, a one -eightieth and a 
one-twentieth scale. The total required range or apparent size change was obtained by 
moving away from one model, then switching to the other and moving from it. An ex- 
ample of the type of model used is shown in figure 11. This model, which is from the 
LMS, contains the lighted docking target in one of the CM docking windows. The dock- 
ing probe and the CM conical portion were made of rubber to protect the probe and 
cameras in the event of inadvertent collision. 



Figure 11. - Docking model of CSM 
in lunar docking simulator. 


All TV systems are black-and-white, 
high-resolution (greater than 1000 TV lines) 
systems. Each system represented the best 
state of the art at the time of procurement. 
Since that time, however, these systems 
have been undergoing almost continuous re- 
work to improve basic performance and 
reliability. 

Sun, earth, moon, spotlight, and other 
lighting effects were introduced in the 
TV/model systems by high- intensity lamps 
surrounding the models. Both mechanically 
controlled lamps and switched banks of 
lamps were used with reasonable success. 

Both the TV/model and electronic- 
image techniques have produced satisfactory 
displays for stationkeeping and docking. In 
the EIG technique, complex shapes cannot 
be drawn; therefore, realism is significantly 
less. Conversely, the EIG is a much 
simpler system to maintain and operate. 
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With the TV/model technique, external features such as windows, antennas, and dock- 
ing aids can be portrayed very accurately. These features are extremely important, 
especially at the close-in docking distances. The picture fidelity obtainable with the 
TV/model system must be weighed against the complexity of the electromechanical de- 
vices required by this system. The TV/model technique has been animated so success- 
fully in the mission simulators that full-scale -vehicle simulation for docking is no 
longer considered necessary, as it was in early Apollo training. 


Near-Body Scenes 

Scenes of the near body while in orbital flight cover the altitude range above the 
earth or the moon from 8 to approximately 1000 nautical miles. At these altitudes, the 
surface was assumed to be reasonably smooth, and terrain that appeared three dimen- 
sional (3-D) was not required. Near -body scenes were necessary for two purposes. 

The first was as a general reference from which the pilot could evaluate his attitude 
and estimate his position over the terrain. To meet these needs, horizon position, 
groundtrack movement, and general continental features were required. The second 
purpose was for landmark identification and tracking. To meet these requirements, a 
more detailed terrain scene was necessary, and the spacecraft position relative to the 
scene had to be more exact. For the earth, color was a highly desirable feature in ter- 
rain identification. For either function, several additional features were desirable, 
such as a day -night terminator and the highlight brightness that would approximate the 
out-the -window scene. Regarding the accuracies, the following parameters are noted: 


Scene 

Attitude function 

Landmark function 

Position of the horizon nadir, or other 
reference in the field of view, deg . . . 

2 

0.5 

Groundtrack movement (azimuth angle), 
deg 

2 

.5 

Size of landmasses, percent 

10 

10 

Horizon curvature, percent 

10 

5 

Resolution — general, deg 

0. 5 

.5 

Landmark areas, a deg 

— 

.1 


a Landmark area was defined generally as a 10- mile -radius circle about the spe- 
cific landmark. The transition from the accuracy of the landmark area to the general 
scene should occur over a 100-mile radius. 
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For the attitude function, the allowable distortion should permit identification of gross 
continental features. For the landmark function, the allowable distortion should permit 
easy identification of landmass features, capes, bays, peninsulas, river basins, major 
craters on the moon, and so forth. 


In Project Mercury, the view through the periscope and through the window was 
simulated in what might be termed ”moving-base devices.” The periscope was simu- 
lated in the air -lubricated free-attitude (ALFA) trainer (fig. 12) by viewing a 12-foot- 
diameter rear-projection screen. The nadir scene was projected on the screen from 
a hand-painted strip film. Considering the large distortion of the spacecraft and trainer 
periscopes, the basic requirements of attitude reference and recognition of gross con- 
tinental features were met. The requirement for window simulation in Project Mercury 
was uniquely tied to yaw-angle identification while in retrofire attitude. This need arose 
from an inflight problem during one of the early Mercury flights. Before the following 
flight, a yaw recognition device had been conceived and fabricated. The simulation con- 
sisted of a 32 -foot-diameter screen curved to represent a portion of a globe 63 feet in 
radius. The shape was obtained by inflating an airtight envelope consisting of one 
translucent and one transparent Mylar sheet. A filmstrip depicting moving cloud cover 
was projected onto the translucent screen. The crewmember standing at the center 
and approximately 2 feet from the dome was at the proper scaled altitude. A simple, 
hand-held box outlined his window. Using this simulation, the crewmember could ob- 
serve any yaw angle and readily learn to 
identify the yaw angles of interest while 
looking toward the horizon. 



Figure 12.- Air -lubricated free- 
attitude trainer. 


During the Gemini Program, the near- 
earth scenes were provided in the mission 
simulators. Two different techniques, both 
of which met the basic attitude-reference 
requirement, were used. At the comple- 
tion of the Gemini Program, the equipment 
was updated and installed in the CMPS and 
the LMPS. 

The CMPS system (from the MSC- 
based GMS) used a 6-foot-diameter globe, 
an articulated probe, and a closed-circuit 
TV system. Modifications from the GMS 
included a new earth globe and a new sup- 
port system for the globe and probe. The 
probe exit pupil was positioned over the 
globe as a function of altitude and latitude. 
Rotation of the globe produced the proper 
longitude. Spacecraft rotations were intro- 
duced by motion of optical elements within 
the probe. The updated globe was built to 
accurate sphericity requirements and artis- 
tically rendered with high detail in selected 
landmark areas. The sphericity plus a 
stable probe mount provided good horizon 
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positional accuracy and curvature up to an altitude of 4000 nautical miles. An artifact 
in the globe and probe system was the need to nutate the probe in azimuth as a function 
of latitude, an effect that complicated the probe drive equations. 

The LMPS used a flying spot scanner system (from the KSC -based GMS) with film 
as the data-storage element. Latitude and longitude were produced by film translation, 
and spacecraft motions were introduced by electronic manipulation of the flying spot 
scanner output. The scanner pattern was spiral and centered at the nadir to produce 
a clean, sharp horizon. To provide equal element spacing as measured from the view- 
point in the spacecraft, the spiral scan spacing was nonlinear. The design resolution 
was equivalent to the best high-resolution TV raster systems. In the GMS, two parallel 
systems were used to produce a semblance of color. However, in the modification to 
adapt this system to the LMPS, this provision was eliminated. The modification also 
allowed simulation of an altitude range from 2500 feet to 100 miles by using zoom optics, 
zoom electronics, and a series of various film scales. The remainder of the LMPS 
modification was directed toward improving overall quality of the visual display by using 
a larger film format and improved electronics. Even with these improvements, the 
LMPS system has not proved as stable and as flexible as the more conventional mechan- 
ical and optical systems. 

The LMS used a system similar in certain aspects to both of the previously de- 
scribed systems. In the LMS, an articulated probe and closed-circuit TV viewed a 
filmstrip of the near body. The LMS films and the LMPS films were actually the same 
image material printed at slightly different scales. The major difference in the sys- 
tems was that, in the LMS, four windows were active and four probes were required, 
whereas, in the LMPS, the display was provided to one forward window and to the over- 
head window. Furthermore, the LMS scene requirements included landmark identifica- 
tion and tracking in addition to the vehicle attitude -reference task. In the LMS, a 
common filmstrip was projected through zoom optics onto four screens. The altitude 
range from near zero to orbit was simulated by a combination of optical zoom and film 
changes. The probes were mounted at a fixed distance above the screens and articu- 
lated with the ability to scan to any point on the screen. At the higher altitudes, spher- 
ical distortion was introduced by moving additional optical elements into the projection 
chain. The horizon was produced at the higher altitudes by illuminating an area smaller 
than full-screen size. At altitudes below 100 000 feet, a servomechanism-operated 
mirror system surrounding the screen produced the horizon. The lunar scene films 
used were, in chronological order, artistic rendition of the front side coupled with 
artistic imagination for rendition of the back, artistic rendition updated with Lunar 
Orbiter data, Lunar Orbiter photographs photomosaicked into a filmstrip, and Lunar 
Orbiter photographs photomosaicked with lunar photographs from Apollo flights. Final 
configuration of the film consisted of Lunar Orbiter strips for the high-altitude, full- 
orbit scenes and Lunar Orbiter strips mosaicked with Apollo photographs for the low- 
altitude scenes in the vicinity of the lunar landing site. 

Several problems were associated with the system that materially reduced the 
usefulness of the LMS. A problem resulted from the splitting of the film image to four 
screens. The illumination on each vidicon was one-third to one-half of the desired min- 
imum. Another difficulty involved the zoom optics. The design required no movement 
of the optical axis with zoom. The dynamic wander of the original hardware was such 
that the usable zoom ratio was restricted to 3 from the design ratio of 10. The wander 
also made registration difficult to maintain when switching from one to a second film 
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scale. A problem was also associated with the film graphics. It was not practical to 
obtain continuous filmstrips with the information content desired. The Lunar Orbiter 
strips with Apollo photographs were available only for small areas of the moon. Also, 
framelet lines in the Lunar Orbiter strips were reproduced just as vividly as the craters 
and rilles. Furthermore, in the Lunar Orbiter films, it was not possible to simulate 
the effect of the sun elevation angle. Hand -painted films could have alleviated certain 
of these problems; however, the cost in manpower and time was prohibitive. 

The overall effect of these problems was a degradation in the LMS fidelity, which 
necessitated use of other techniques and facilities to complement the LMS. For in- 
stance, for the landmark identification and tracking task, detailed briefings and lunar 
map reviews were held with the crew. The accuracy of the spacecraft navigation sys- 
tem also helped, because the crew rarely had to search for a landmark during flight. 

The desired target was usually where mission planning said it should be. 

The CMS near-body simulation, from the outset, was mainly for the purpose of 
landmark tracking. The system consisted of direct view of color film projections of 
near-body imagery. Only such a direct-view system could provide the resolution spec- 
ified. This system, known as the mission effects projector (MEP), was used in the 
four cabin windows and in the unity-power telescope. In the MEP, the image was pro- 
jected through a series of optical devices onto a spherical screen. This screen served 
as the input of the infinity image system. The optics were driven by servomechanisms 
to simulate spacecraft rotations, limited altitude effects, day-night terminator, and so 
forth. Nadir position was introduced by driving the film, and large altitude changes 
were provided by dissolving to films with different scale factors. The MEP represented 
an extremely complex electronic, mechanical, and optical device. For instance, each 
MEP had over 30 computer-controlled servomotors and over 40 other computer- 
generated signals. Some compromises were required in the final operating configura- 
tion: the maximum detail scenic area, as measured from the spacecraft, was limited 
to a 90° cone centered about the nadir; the minimum altitude simulated was 100 nautical 
miles; and the film centerline was placed approximately along the groundtrack. The 
first of these was the greatest limitation, but it was partially alleviated by using a cloud 
cover that moved with the earth to fill the scene to the horizon. 

The films covered relatively narrow strips centered on the groundtrack; and, be- 
cause of retrogression of the orbit (westerly movement of the ascending node), 17 con- 
tinuous strips were required to cover the Apollo earth-orbit mission. To resolve the 
round-to-flat mapping problem and the orbit-to-orbit scene repeatability, an extremely 
accurate globe, used as the data source, was photographed by a special modified-slit 
camera. The preparation of the filmstrip from this globe is described in reference 1 . 

The altitude variation for near -body orbits was specified as 100 to 1000 nautical 
miles and was obtained by a combination of three film scales with a 2. 15:1 zoom capa- 
bility. Over 250 feet of film stored in four film cassettes were required for each MEP 
system. 

The CMS MEP system, like the LMS, did not meet all the initial design objectives. 
The complexity of the mechanical-optical device caused problems, and the number of 
MEP systems required to fill the windows of the three mission simulators made im- 
provements extremely costly. The first of the difficulties concerned the illumination 
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system, in terms of both the level of light and the uniformity of illumination across the 
full FOV. The relatively low level of illumination manifested itself in many other prob- 
lem areas. The system design required an extremely high luminous flux on the surface 
of the film. Even with this flux, the final brightness as measured from the window was 
approximately one -fourth of the originally, specified 4.5 ft-L and approximately 
one -eighth of the desired illumination to simulate a highlight brightness representative 
of a true out-the -window scene. With the high light flux, the film would be destroyed 
almost immediately by infrared and ultraviolet radiation. To limit this damage, heat 
absorption and rejection filters were used between the arc lamp and the film. Addi- 
tional film cooling was achieved by a very high, continuous airflow. This high airflow, 
in turn, caused flutter and eventual destruction of the film. In the final mode of opera- 
tion, a compromise was selected that accepted some film deterioration caused by the 
heating and flutter and a scene illumination that required a relatively dark crew station. 
In the simulator, the crew made use of the panel lighting and the small floodlights, 
whereas in the spacecraft the sun illumination through the windows was generally 
sufficient. 

For other deficiencies in the system, practical solutions were never found, and, 
as a result, procedural workarounds were developed to alleviate the impact on training. 
One such deficiency involved the resolution of the imagery that was presented to the 
crewmember in the crew station. Although the inherent resolution of the direct-view 
film system satisfied the specified requirements, copies of the film could not be pro- 
duced consistently with the same high image quality. The processing of 100-foot lengths 
of film does not produce results of the quality that can be achieved by copying individual 
photographs. A 30-percent degradation was not uncommon. Another problem involved 
the impossibility of maintaining the proper film positioning accuracy over the 80 feet of 
film in each of the cassettes. Minor film stretching and warpage introduced errors of 
significant magnitude. In addition, the drive system of the film did not have nearly as 
tight a tolerance as required. Finally, a problem existed with the colors in the film. 
While the films themselves contain very saturated colors, the projector tended to mute 
and mutilate the colors as displayed in windows — for instance, the blue oceans 
appeared almost black in the windows. 

In both the CMS and the LMS, a defect existed in that the star simulation would 
bleed through the near-body scenes. The equipment, as originally designed, contained 
hardware to occult the stars in a circular pattern of the same diameter as the near body 
would subtend. This hardware proved difficult to maintain, was nonlinear with position 
and shape of the body in the FOV, and, as a result, did not successfully occult all the 
stars. Finally, a shortcoming of all near-body simulations was the low scene bright- 
ness. This condition required the crewmen to dark adapt to discern the necessary de- 
tail out the window. 

Significant funds have been spent in developing the near-body simulations for the 
various space-flight vehicles. It is recommended that, in the future, the requirements 
for out-the -window scenes be very carefully analyzed and that extreme care be taken 
to limit the simulator requirements to those obtainable with reasonably simple hard- 
ware. For example, in the CMS, only the unity-power telescope in reality required 
stringent tracking accuracies. The other four active windows could have been animated 
with much less sophisticated hardware. Experience has also shown that window-scene 
generators should be more integrated as in the LMS and the CMPS than the system-per- 
window such as in the CMS. Such design considerations in future applications should 
both reduce initial costs and result in lower maintenance effort and costs. 


26 


Landing Scenes 

Landing scene simulation was required only in the LMS for training in the lunar 
approach and landing phases. The altitude range desired was from a high-gate or 
breakout altitude down to and including touchdown. The scene was required to provide 
the crewmember with attitude and altitude information plus pertinent surface -feature 
details. In all other programs (for instance, during earth entry and landing), there was 
a minimum of crew activity relative to the window displays; therefore, little or no ex- 
ternal scene simulation was supplied. In the LMS, the requirement was defined as a 
continuous scene from an altitude of approximately 15 000 feet to touchdown. The orig- 
inal requirement at the time of simulator procurement was for a generalized lunar sur- 
face containing representative features of the moon. This requirement was expanded 
subsequently to include modeling of the actual landing sites. Three-dimensional sur- 
face detail was required when surface irregularities became visible to the crewman. 

For the lunar landing simulation, the attitude at which surface features became impor- 
tant was defined as 2000 feet. An additional requirement was the casting of shadows 
such as would be caused by local surface irregularities when illuminated with collimated 
sunlight. 

The visual acuity requirement was to identify objects subtending approximately 
0.5° at the pilot’s eye. This angle represents an object the size of a 175-foot -diameter 
crater observed from 45° at an altitude of 10 000 feet, or a rock approximately 1 foot 
in diameter observed from 100 feet. The positional accuracy of the information in the 
window was specified as 0. 5° measured at the eye. In addition, the simulated space- 
craft should be capable of landing; that is, the eyepoint should approach its scaled 
height above the model surface at touchdown. The lunar-surface terrain should rep- 
resent the broad features to an accuracy of approximately 50 feet. In the landing area 
(approximately 2 miles in diameter), this accuracy is increased to approximately 
10 feet. The surface should be enhanced with rocks and small craters. The size, num- 
ber, and distribution of these rocks and small craters are based upon statistical lunar- 
surface data. The size of rocks and craters should approach the lowest modeling limit 
of 0. 02 inch. 

As initially delivered, the LMS was designed to meet the specified 15 000-foot- 
altitude range capability with a combination of the closed -circuit TV/film technique de- 
scribed previously for near-body scenes, and a relatively conventional closed-circuit 
TV/3-D model system. This model system, known as the landing and ascent (L&A) 
system, was used below 1200 feet. The model was 1:1000 scale with three typical ter- 
rain types arranged in 120° pie sections; one each for hummocks and small fissures, 
boulders and large fissures, and craters. The distribution of these features was such 
that approximately 35 percent of the surface could be used for landing. Shadows were 
simulated by painting the model. The solar elevation angle was assumed to be 45°. 
Overall, this system was determined to be inadequate for training. The major short- 
coming was the lack of continuity from breakout to touchdown caused by the film system 
problems mentioned in the discussion of near-body scenes. An additional shortcoming 
was the lack of realism in the landing area model. An upgraded system, which used a 
3-D model from breakout altitude to touchdown, was developed for training of the first 
lunar landing mission crews. Maximum altitude of the model simulation was increased 
to approximately 12 000 feet, and the model scale was established at 1:2000. Two sig- 
nificant features were added — an accurate model of the targeted landing area and a 
collimated light source to illuminate the surface and produce lunar -terrain shadows. 
Figure 13 is a photograph of the upgraded system. The model was viewed by an 
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Figure 13.- Lunar-surface model (scale 1:2000) of lunar module simulator. 


articulated probe with a 110° FOV. To produce the large depth of field required for 
viewing the surface obliquely, the probe had remote focus capabilities and tilt correc- 
tion. The rotations in yaw and roll were unlimited, but pitch rotation was limited to 
-10° to +110°. The probe was driven horizontally across the surface in latitude and 
longitude, while the surface moved vertically to simulate altitude. The landing area 
simulated was approximately 5 by 8 nautical miles. The image was relayed from the 
probe to one window of the LM display system by the high -resolution closed-circuit TV. 
Switching was available to supply the image to either of the two LM front windows. 

Several undesirable characteristics still existed with the upgraded L&A system. 
The closed-circuit TV performed according to expectations only with continuous main- 
tenance. The horizon simulation, which was generated by mechanical rings around the 
model, exhibited errors of 3° to 5° for off-nominal trajectories. Duplication of the re- 
flectivity of the lunar environment required continuous testing with each new surface 
installed. As the desired sun elevation angle increased above 12°, the probe shadow 
became very prominent and the actual touchdown area was in the shadow at angles above 
18°. Various means of floodlighting this area alleviated the shadow but compromised 
the sun collimation. 
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Landing simulators used throughout the aircraft and airline industries for training 
pilots are in some ways similar to the L&A but are much less massive and, therefore, 
have lower demands upon servosystems. New designs for spacecraft landing simulators 
should take advantage of the design of these commercial systems. The use of colli- 
mated light to illuminate model surfaces should be carefully analyzed. Continued ef- 
forts should be expended toward producing a brighter image on the TV screen. Tests 
have been made with some degree of success on the use of black phosphors mixed with 
bright phosphors to provide a greater contrast ratio from less scattering of the light. 
Other techniques should be studied. Although simulation of the lunar landing did not 
require color (since the black-and-white system was very suitable), earth landing sys- 
tems will probably require color; and the development of a tricolor high-resolution TV 
system is desirable, particularly for night approach simulation. 


Concluding Remarks 

Beginning with a simple simulation requirement to provide an out-the -window 
scene as a backup spacecraft-attitude reference in the Mercury flights, visual display 
simulation systems for the lunar landing mission have grown to become a major but 
necessary element of the Apollo mission simulators. For each visual task of the lunar 
landing mission, a visual scene was simulated through an infinity optics system in the 
mission simulator. Although the complexity and cost of these devices were significant, 
their use in mission training was mandatory. 


MOVING-BASE SIMULATIONS 


Various moving-base simulators have been used throughout manned space -flight 
programs for crew training. The primary objective has been to familiarize flight crews 
with the dynamic environment and to present them with visual realism of the operational 
task. The use of moving-base simulators and the experience gained while developing 
and operating such systems are described in this section. 

A moving -base simulator is a device in which the major components have physical 
motion. The crew station or the crewmembers (or both) are subjected to the physical 
motion. The space-flight environments of earth launch, earth orbit, cislunar flight, 
lunar orbit, lunar landing, lunar-surface activities, lunar launch, atmospheric entry, 
and earth landing all contain elements of sight, sound, and touch that are not in man's 
normal experience. In these new environmental conditions, man has been asked to 
perform certain tasks, such as entry, docking, launch abort, and lunar landing. In 
preparation for these tasks, moving-base simulators have been used successfully to 
familiarize the crewmember with the anticipated environment and to confront him with 
the operations he would be expected to perform. New environments have consisted of 
launch acceleration profiles, reentry deceleration profiles, weightlessness, and the 
lunar gravity. Human centrifuges have been used to simulate the acceleration and de- 
celeration profiles. The dynamic crew procedures simulator has been used to simulate 
the launch profile, including noise and vibration. Weightlessness has been simulated by 
aircraft zero-g flights and by water-immersion facility sessions. (These two facilities 
are not included in the category of moving -base simulators. ) Training for the lunar- 
gravity environment has been accomplished through the use of the partial-gravity 
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simulator (fig. 14), the mobile partial-gravity simulator (fig. 15), the lunar landing 
research facility (fig. 16), and the LLTV (fig. 5). 

Although training for tasks such as reentry, docking, launch abort, and lunar 
landing has been accomplished on fixed-base simulators, crew proficiency for each 
of these tasks has been improved with moving-base simulators. The moving-base de- 
vices were used to add realism to the simulation by presenting realistic cues inherent 
in body acceleration and binocular vision. 



Figure 15.- Mobile partial-gravity 
simulator. 
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Application of IV\oving-Base Simulators 

Several moving-base simulators have 
been used for crew training in environmental 
familiarization and development of task per- 
fection. In preparation for the early space 
flights of Project Mercury, when little or 
no experience existed in the new environ- 
ments, several devices were used to famil- 
iarize the crewmembers with anticipated or 
possible dynamic situations. The multiple - 
axis spin test inertial facility (fig. 17), 
which was a simulator built by the NASA 
Lewis Research Center, consisted of three 
gimbals individually powered by compressed- 
gas thrusters. Angular rates from near 
zero to more than 60 rpm could be gener- 
ated. The crewmembers were whirled to 
rotational speeds at which disorientation oc- 
curred to familiarize them with this dis- 
orientation and to enable them to practice 
stopping the motions by use of the Mercury 
spacecraft hand controller and angular rate 
instrument displays. The tests served mainly to build confidence that, in the event of 
a gross automatic control system failure, the crewmembers could regain control of the 
vehicle and stop all tumbling. 

The human centrifuge (fig. 18) at the Naval Air Development Center, Johnsville, 
Pennsylvania, was used for crew training in acceleration profiles and for engineering 
evaluation of crew-station equipment. The gondola of the centrifuge was equipped with 

the vehicle hardware required to support 
the astronaut in launch and reentry phases 




Figure 16.- Lunar landing research 
facility (Langley Research Center). 


Figure 17. - Multiple-axis spin test 
inertial facility (Lewis Research 
Center). 


Figure 18. - Centrifuge (Naval Air 
Development Center, Johnsville, 
Pennsylvania). 
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of the mission. To further duplicate flight conditions, the gondola was evacuated to the 
reduced cabin pressure of actual flight. Six-degree-of-freedom equations of motion 
were used to animate the display panel and to generate the acceleration profiles. In 
the final training sessions for Project Mercury (August to September 1961), the crews, 
equipment, and procedures were evaluated by simulation of the complete three-orbit 
mission from preflight physical examination through countdown, launch, three orbits, 
reentry, recovery, and postflight debriefings and physical examinations. Baseline 
medical data for comparison with the flight data were derived from these sessions. 

The ALFA trainer (fig. 12) was basically a pseudo-Mercury spacecraft mounted on a 
spherical air bearing. This near frictionless support, coupled with a combined 
astronaut -plus -trainer center of gravity at the center of the ball, produced an accurate 
simulation of spacecraft motion as far as attitude control was concerned. The struc- 
tural support systems and the effects of the one-g field on the trainer limited the yaw 
and pitch motions to ±35°. Roll was unlimited. All three attitude -reference systems 
(periscope, panel instruments, and window) were available to the crewmember. For 
the periscope display, a 10-foot-diameter screen was viewed through optics simulating 
the wide-angle view of the vehicle periscope. A moving earth scene of the orbital track 
was back projected onto the screen. This display was relatively accurate for deviation 
angles up to 25°. For the panel displays, actual vehicle hardware was used to measure 
the attitudes and rates and to display these values to the crewmember. For the view 
through the window, a lighted horizon and a generalized star field were provided. Mo- 
tion of the trainer was controlled by the crewmembers' use of compressed-air jets. 
Mercury spacecraft control systems were simulated. Disturbances that could be pro- 
duced by misalinement of the retrorockets also were simulated by compressed-air jets. 

As the manned space -flight program progressed and experience was gained in 
space flight, crewmembers and engineers became more familiar with the dynamic en- 
vironment. Crew performance in space was demonstrated, and many of the previous 
unknowns were no longer areas for concern. The performance of new tasks was neces- 
sary to achieve the goal of placing a man on the moon. Thus, the emphasis previously 
placed on dynamic environment familiarization became secondary to training for per- 
formance of special tasks. The tasks of docking, lunar landing, and traversing the 
lunar surface were approaching, and crew experience was needed. To meet this re- 
quirement, a new generation of moving-base simulators was developed for crew train- 
ing. The Langley rendezvous and docking simulator (fig. 19) used a crew station 
supported in a gimbal that was suspended from a bridge crane. The crew station had 
six degrees of freedom and operated in conjunction with a stationary target vehicle. 
Primary attention was given to crewman position, control assembly, control modes, 
viewing window configuration, docking aids, and target-vehicle geometry. Development 
work on docking procedures was accomplished as well as crew training and evaluation 
of docking aids. This simulator was used for Gemini docking and for both Apollo dock- 
ing configurations (CM and LM). 

The MSC translation and docking simulator (figs. 20 and 8) was a six-degree-of- 
freedom simulator used primarily for crew training. The hardware consisted of a crew 
station mounted in a three-axis gimbal. The gimbal was supported by an air-bearing 
carriage to permit lateral motion. The two remaining translations, longitudinal and 
vertical, were simulated by target motion. These two motions were reversed to give 
the proper directional illusion of crew- station motion. Primary emphasis was placed 
on vehicle configuration and visual environment. Various control system modes were 
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simulated, and flight-type docking aids were 
used. Simulator configuration included 
Gemini docking, Apollo LM-active docking, 
and a modified CSM-active docking, in which 
CSM mass properties were programed into 
the simulator with control from the LM 
Figure 19. - Rendezvous and docking crew station, 
simulator (Langley Research 

Center). The dynamic crew procedures simu- 

lator (fig. 21) consisted of a crew-station 
gondola supported in a gimbal that was can- 
tilevered into a spherical dome. The design of this simulator was based on the idea of 
presenting the rotational acceleration to the crewmember while separating the velocity 
cues into a visual presentation. The interior of the dome was used as a screen on which 
an earth image or star field could be displayed. One of the primary features of the 
simulator was that it could present the dynamic environment (noise and vibration) of 
launch and reentry for crew familiarization. Procedure development and practice on 
the simulator have included launch, launch abort, reentry, and rendezvous. The simu- 
lator, which originally was designed and built in Gemini configuration, also has an 
Apollo CSM configuration (fig. 9). 



Figure 20. - Translation and docking 
simulator (Gemini). 


The lunar landing research facility (fig. 16) was used for research and for crew 
training associated with the piloting of a vehicle in simulated lunar gravity. This out- 
side facility consisted of a gimbal-mounted vehicle suspended from a traveling bridge 
crane. The piloted vehicle, originally with the crewman seated and later modified to 
a standup configuration, had an operating envelope of 180 feet vertically, 360 feet lon- 
gitudinally, and 42 feet laterally. Two operational modes were used. The first mode, 
used primarily for pilot indoctrination and system test, simulated the lunar-gravity en- 
vironment and rocket-engine lift through the use of the translation drive systems. The 
second (simulation) mode used the main rockets and onboard fuel to develop lift while 
the translational drives supported five -sixths of the vehicle weight to simulate lunar 
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gravity. The simulation mode allowed ap- 
proximately 2 minutes of operation whereas 
the first mode afforded more than 20 min- 
utes of continuous operation. Evaluations 
of control system parameters and piloting 
techniques associated with lunar landing 
touchdown were conducted. Operation with 
various landing models allowed evaluation 
in the area of obstacle avoidance and a 
limited look at surface dust effects. 

The LLTV (fig. 5) is afree-flight 
vehicle consisting of a tubular frame on 
which a crew station, a jet engine, lift 
rockets, attitude control rockets, control 
electronics, and associated equipment are 
mounted. The jet engine, which was 
mounted vertically, provided main power 
for takeoff and supported five-sixths of the 
vehicle weight during simulation of the lunar environment. The vehicle was used to 
simulate the lunar landing from an altitude of 500 feet to touchdown. Operations were 
conducted over an airport runway and consisted of several familiarization flights prior 
to the lunar simulation flights. A fixed-base LLTV simulator (fig. 22) was used to 
familiarize the pilot with crew-compartment instruments and controls. Use of the 
simulator allowed the pilot to practice LLTV procedures and to become familiar with 
vehicle operations. 

The partial-gravity simulator (fig. 14) consisted of a gimbal supported from a 
pneumatic cylinder. The pneumatic cylinder provided lift to support a proportional 
amount of a crewman's weight. The simulator was used to familiarize crewmembers 
with lunar-surface mobility. Use of lunar tools was practiced. A mobile partial- 
gravity simulator (fig. 15) also was used to familiarize the crewmembers with lunar- 
surface mobility. The two simulators were of the same basic design except that the 
mobile unit was suspended from a truck-mounted tower. This arrangement was used 
to extend the operating range and to allow investigation and familiarization with running 
under lunar-gravity conditions. 



Figure 21.- Dynamic crew procedures 
simulator (Gemini). 



Figure 22 . - Lunar landing training 
vehicle simulator. 


Simulation Experience 

In general, the design, operation, and 
modification requirements of moving-base 
simulators are similar to those of other 
simulation hardware. However, in addition 
to the greater emphasis on crew safety re- 
quired, some unique features must be con- 
sidered in the design and operation of 
moving-base simulators. 

Moving -base simulators usually are 
designed for a special task or set of tasks. 
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The design must concentrate on the simulation of those tasks while minimizing the un- 
desirable side effects that are inherent in moving hardware. To overcome undesirable 
side effects and to accomplish successful moving-base simulation, innovation and 
unique approaches are needed, such as the separation of simulated acceleration cues 
(seat of the pants) and velocity cues (visual), the use of airbearings to minimize other 
motion cues such as rumble, special servosystem design to keep undesirable dynamic 
cues outside the frequency and amplitude domain of sensory perception, rotation about 
the individual body center of gravity to equalize force on extreme ties, painting, lighting 
to hide support or enclosure structure, and so on. The hardware design as well as the 
computer software must take into account the man-in-the-loop aspect. Convenient in- 
gress and egress provisions are required and actual man-machine interface is neces- 
sary; however, only the pertinent interface should be included. Special programing, 
such as drive-system compensation, may be required for proper hardware perform- 
ance. An overall systems analysis should be performed before design finalization to 
ensure that optimum simulation can be performed. Size and weight are basic consid- 
erations in the design. The simulator size is dictated by flight-vehicle configuration, 
and the design weight affects drive-system design and overall system complexity. 
Structural integrity must be consistent with the dynamic environment and the man- 
machine interface. Fidelity of the simulations is dependent on a satisfactory balance 
of these parameters. Controls and displays usually are limited to those necessary to 
accomplish the unique task or tasks. Cockpit displays other than those of the space- 
craft are necessary in some moving-base simulators, such as the LLTV, because of 
their operating requirements. Special effects of lighting and sound have been used to 
add significant cues for the performance of a given task. Lighting also can be used to 
enhance the simulation. For example, in the MSC TDS, the target vehicle was illumi- 
nated to make it stand out against a subdued background. This technique is used to re- 
duce the false cues given by supporting structures and surrounding walls. Foremost 
in the mind of the designer must be the characteristics of the spacecraft or the situa- 
tion being simulated. If characteristics peculiar to the simulator overshadow the situa- 
tion or spacecraft being simulated, the simulator will be of little value. 

Moving-base simulator operations have requirements in addition to those of other 
simulators. These considerations exist because the crewman experiences the dynamic 
environment and because some physical limitations with moving hardware do not exist 
with electronic or optical simulations. The interface of the crewmember with the hard- 
ware is a prime consideration in the design and basic configuration. Crew restraints 
and hardware arresting gear are a part of the basic design. Computer program scaling 
and signal limiting should be compatible with the dynamic environment to be simulated. 
Operating procedures need careful consideration to allow successful simulation. These 
procedures include inspections and preventive maintenance; preflight checkout; and 
power-up, power-down, and backup procedures. The key to crew safety is a knowledge- 
able and alert operator with positive control over the motion systems. Velocity, accel- 
eration, and position limits are a part of moving-base simulation. The task being 
simulated must be considered in the setting of these limits. In addition to these physi- 
cal limits, equations-of-motion scaling limits and electrical limits are included to 
provide fidelity of simulation and safety of operation, respectively. These constraints 
are an inherent part of moving-base simulators and cannot be overlooked when consid- 
ering operations. 

As with any hardware, a development period is needed when producing a moving- 
base simulator to permit optimum engineering trade-offs. Simulator design in this 
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area is unique because a limited number of simulators of a particular configuration are 
built, possibly only one. Therefore, a preliminary fabrication and checkout period, in 
which prototype hardware is developed and tested before production, could be used to 
develop better hardware and to eliminate operational problems. Another design consid- 
eration should be the use of off-the-shelf items to minimize special equipment, which 
is hard to replace and usually expensive. In addition, it should be remembered that 
simulation equipment has a high use rate and needs to be designed with a high degree of 
reliability. The computer program (analog or digital) will in some ways be unique be- 
cause of the interface requirements with moving hardware. The nature of the hardware 
must be considered and special formatting or signal conditioning accomplished to per- 
form a valid simulation. In addition, it is useful to be able to verify the computer pro- 
gram independent of the moving hardware. A computer self test, or program designed 
to close the loop on itself, can be a valuable tool in program verification and checkout. 


Concluding Remarks 

Various moving-base simulators have been used in manned space flight to add a 
degree of fidelity in certain flight regimes not available in fixed-based simulations. In 
spite of design complexities, additional operational procedures, and safety considera- 
tions (compared to fixed-base devices), moving-base simulators will continue to play a 
significant role in training and simulation for future programs. 


SIMULATOR CONFIGURATION MANAGEMENT 


The three manned -space -flight programs (Project Mercury, the Gemini Program, 
and, in particular, the Apollo Program) have emphasized progressively the requirement 
for a firm simulator-configuration-management program. The requirements for 
simulator-configuration management exist for the same reasons as those of spacecraft 
configuration management; that is, the need to know the vehicle configuration at any 
point in time and the need to know the vehicle future or desired design configuration. 

The converting of the vehicle, or in this case, simulator, from an actual configuration 
to a design configuration must be by means of an organized and systematic procedure — 
one that will provide the highest crew-training return with a reasonable manpower and 
dollar investment. The guidelines in this section describe how this balance, or goal, 
has been achieved closely in past programs and how it can be realized fully in future 
programs. The following discussion defines the necessary building blocks for simula- 
tor configuration identification: configuration tracking, configuration control, and con- 
figuration accountability — the total of which is synonymous with configuration 
management. 


Configuration Tracking 

The major crew-training (mission) simulators for Project Mercury and for the 
Gemini and Apollo Programs all were developed and constructed by industry contractors. 
Each simulator constituted a contract end item and was initially designed to a basic data 
package, largely supplied by the spacecraft prime contractor through NASA. This data 
package was serviced and updated in total until the simulator preliminary design review 
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(PDR) and formed the basic mathematical model and hardware design definition for each 
respective simulator. At the PDR, the simulator reached a contract definition stage 
(usually, although somewhat erroneously, referred to as a contractual "design freeze"), 
beyond which all simulator updates or changes to the spacecraft baseline data package 
constituted a design change and required a corresponding simulator contractual change. 
It is at this point that the terms "modification, " "configuration control, " "in-line modi- 
fications, " and "modification kits” assume their full significance and the execution phase 
of modification activity begins. This modification activity usually commences prior to 
formal contract delivery of the basic simulator to NASA. 

In its simplest terms, a spacecraft modification is a class I or class II change to 
the flight vehicle that requires duplication in the simulator to prevent a serious degra- 
dation in crew training or simulator configuration. A class I change is an out-of-scope 
modification to the flight vehicle and is initiated by a contract change authorization 
(CCA) from NASA to the spacecraft prime contractor, A class II change is an in-scope 
modification that the spacecraft prime contractor finds necessary to implement, and 
does so without a change or amendment to the contract. All spacecraft modifications 
in either class are reviewed and considered for implementation into the simulator. A 
routine, thorough review of all these changes is hardly acceptable in terms of man- 
r hours (at one point in the Apollo Program, the change activity was running at 75 to 

100 changes per week), and timesaving shortcuts can be identified quickly. Examples 
of shortcuts that are used on the Apollo Program will be given later. First it is neces- 
sary to define the methodology and technique used in identifying spacecraft changes 
from a simulation point of view. Through January of 1970 in the Apollo Program, 

1050 changes were approved for incorporation into the CMS alone, and approximately 
700 of these resulted from counterpart spacecraft changes. The following procedures 
can be adapted and used to identify simulator changes (resulting from actual or proposed 
spacecraft changes) for any given program. No attention will be given here to the 
simulation -fidelity requirements relative to a spacecraft change, as that subject is 
covered in other portions of this report. 

1 . Monitor and review regularly the agenda and minutes of the spacecraft Con- 

! figuration Control Panels (CCP's). This activity will normally cover all proposed and 
approved requests for engineering change proposals (RECP's) from NASA and all en- 
gineering change proposals (ECP’s) from the contractor of less than a certain dollar 
value or with less than a certain schedule impact. 

2. Monitor and review regularly the spacecraft Configuration Control Board 

i (CCB) agenda and minutes. This activity will identify high-impact approved or disap- 
proved spacecraft changes and items referred by the spacecraft CCP. 

3. Obtain copies of, and review, the prime contractors' internal change authori- 
zation paperwork. In the Apollo Program, these authorization documents were the 
manufacturing change request (MCR) and the lunar module change request (LCR) from 
the prime contractors for the CSM and the LM, respectively. These documents are 
normally released to initiate a design study and frequently are weeks ahead of RECP, 
ECP, or CCA action. Consequently, the use of this monitoring tool allows routine 
identification of proposed changes much earlier than the activities described previously 
(items 1 and 2); however, care must be exercised in cross-checking these releases 

1 against the NASA CCP and CCB activity for approval authorization. An alternative to 

, this procedure is to obtain the contractor's MCR release-to-manufacturing milestone, 
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which signifies that the MCR is approved for implementation. It should be noted that 
there is no obligation for the contractor always to release an MCR (or a similar type 
paper) for a change, and frequently the contractor does not do so for class II changes. 

4. Routinely review basic system schematics on a per-spacecraft basis as a 
cross-check against items 1 to 3. 

5. Obtain routine distribution of all mission-definition documents and updates of 
these documents within NASA. 

6. Obtain routine distribution of all guidance and navigation onboard computer 
program documentation and pertinent engineering reports. 

7. Establish channels with all NASA associate contractors for applicable space- 
craft data on an as-required basis. 

As mentioned earlier, certain shortcuts can be taken to decrease the NASA man- 
hours required to review and control the rather large bulk of information and documen- 
tation identified previously. Examples of the shortcuts that have been used on the 
Apollo Program and that should be considered on future programs are as follows : 

1. Have the spacecraft contractor categorize MCR's and filter out those clearly 
not applicable to simulator design. Examples are ground -support equipment MCR's that 
are not transmitted to NASA simulation personnel. 

2. Do not submit any simulator change for approval unless the spacecraft counter- 
part is released to manufacturing or the item is considered to be a long-lead -time type 
change. In the past, the released-to-manufacturing milestone has been identified on the 
MCR document; if it is not, a tabulation of this information is required from the 
contractor. 

3. Review CCB directives. This procedure will provide a summary of NASA- 
approved CCP and spacecraft changes and will reduce review of agenda and minutes to 
a cursory level to identify only those proposed changes placed in a deferred status. 

4. Establish a procedure for the spacecraft contractor to audit, screen, and 
identify all class II changes that could be applicable to the simulator configuration. 

5. Initiate parallel shipment of spacecraft-modification data to the simulator 
design contractor or support contractor (or both) as well as to NASA. This procedure 
will enable parallel review and impact analyses of modifications. 

Whereas the previously mentioned simulator modifications may result from a 
spacecraft subsystem change, subsystem improvement, elimination of crew safety 
hazard, elimination of potential single -point failure, change in trajectory or landing 
site, and so forth, there is also a category of simulator improvement modifications 
not contingent upon spacecraft changes. This category is for the improvement of opera- 
tional, maintenance, or training capabilities of the simulator in terms that are evident 
to NASA operations personnel or NASA support contractor modification and maintenance 
personnel. This type of modification has no parallel in the true spacecraft. Either 
NASA or simulator contractor personnel initiate this type of change, although this 
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procedure is not mandatory. However, these persons usually possess the firsthand ex- 
perience and knowledge needed to recognize candidate simulator improvements. When 
simulator history is traced from the first Mercury procedures trainer to the CMS and 
the LMS, a dramatic increase in simulator improvement modifications is apparent. 

This increase can be attributed, in large part, to the justifiable increase in complexity 
in the man-machine interface. For example, whereas the Mercury procedures trainer 
was a rather simple procedural analog training device designed to simulate a somewhat 
repetitive series of missions, the CMS and LMS, each with a powerful computing com- 
plex and complicated MCC interface, were designed to simulate a much larger reper- 
toire of missions. 

In addition to the configuration change identification data discussed earlier, space- 
craft change implementation data must be defined and obtained. These data fall into the 
following areas: 

1 . Internal MSC data such as mission planning and trajectory data 

2. Internal NASA data such as NASA George C. Marshall Space Flight Center 
booster and launch trajectory data 

3. NASA associate contractor data such as the Massachusetts Institute of Tech- 
nology onboard computer programs and necessary supporting documentation for the 
Apollo Program 

4. NASA spacecraft prime contractor and subcontractor vehicle subsystems data 

The process of identifying and obtaining the data listed in items 1 to 3 is simple, but a 
difficulty inherent in item 4 is the undesirability of receiving updates to 500 000 space- 
craft drawings. The method that works well on the Apollo Program is correlation of 
the spacecraft prime contractor MCR or LCR to newly defined spacecraft drawings or 
engineering order (EO) to existing drawings, and transmittal to NASA of the drawings 
or EO’s on microfilm aperture cards. Furthermore, NASA reviews MCR and LCR 
documents immediately after they are released and informs the contractor which poten- 
tial changes will have impact on the simulator; consequently, particular data are iden- 
tified long before the data are released, which is a desirable condition. Also, this 
procedure eliminates transmittal of data for MCR’s that do not have impact on a simu- 
lator. The document that relates MCR's to drawings and EO-type data is called a data 
submittal letter and is a cross -tabulation of MCR number to drawing or EO number. 
After an MCR or LCR is defined as applicable to a simulator, all spacecraft data re- 
leased against it will be supplied to NASA. 

All proposed modifications for the simulator submitted to the Simulator Control 
Panel (SCP) require preparation of a standard form known as a modification request 
(MR). The MR is required to contain the following information: 

1 . The change to the actual spacecraft and its effect on vehicle operation or crew- 
member interface (or both) (not required for simulator improvement modification) 

2. Definition of the counterpart simulator change required to update the simula- 
tor to reflect the spacecraft 
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3. The effect on crew training if the change is not implemented 

4. Spacecraft and simulator effectivity 

5. How, and to what extent, the hardware or software (or both) is to be modified 

6. An estimate of parts cost and source, and the man-hours and computer -hours 
required to implement the modification from preliminary design to final NASA 
acceptance 

7. A schedule of all pertinent milestones including final installation acceptance 

The author of the MR supplies information for items 1 to 4. The NASA simulator 
contractor, who will implement the modification, supplies information for items 5 to 7. 
All MR packages are reviewed and screened for accuracy and relevance before submittal 
to the SCP — which is the next subject and the first step in configuration control. 


Configuration Control 

All MR’s require SCP approval before implementation. The functions and re- 
sponsibilities of the SCP are defined as follows: 

1. Evaluate spacecraft changes that have impact on the simulator. 

2. Evaluate all other proposed changes, such as launch vehicle, mission trajec- 
tory (reset), and simulator improvement, that have impact on the simulator. 

3. Review the availability of spacecraft data for each spacecraft modification 
presented for approval. 

4. Confirm simulator effectivity for a modification. 

5. Assign responsibility for implementation of each modification. 

6. Approve a schedule for each modification based on consideration of the follow- 
ing items: 

a. Mission effectivity and schedule 

b. Crew-training requirements 

c. Simulator availability 

d. Flight controller (integrated mission) training requirements 

e. Difficulty and extent of modification 

f. Cost 

7. Review the total operational and modification status of the simulator. 
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8. Act as the overall configuration management control point by defining any addi- 
tional procedures required for a specific modification, assigning action items, and en- 
suring that the overall modification cycle is operating in a smooth and timely manner. 

Immediately before a scheduled SCP meeting, a pre-SCP meeting is held between 
NASA and simulator support contractor personnel. The purpose of this meeting is to 
review all modifications on the SCP agenda for technical accuracy, format, and com- 
pleteness. In the pre-SCP meeting, the disposition of all new and open MCR's that are 
not ready for presentation to the SCP also is determined. The functional placement of 
the pre-SCP and SCP activities are shown in figure 23. The following categories are 
used in the pre-SCP meeting to classify all MR’s: 

1 . Recommend SCP disapproval of the MR or determine that the MR is not appli- 
cable to the simulator. 

2. Determine that the MR is not yet impacted and that impact is required for con- 
sideration at the next SCP meeting. 

3. Determine that the MR is not impacted because of lack of data and that action 
is required to obtain data. 

4. Recommend approval of the MR to the SCP. 

5. Place the MR in abeyance to be reevaluated at a future NASA- specified date. 

6. Place the MR in a hold status pending more detailed NASA review. 

7. Determine that the MR revision has no effect, and, thus, that the previous re- 
vision level remains in effect. 


8. Determine that the MR affects 
telemetry measurements and should be 
grouped into one master, collective MR. 
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Figure 23.- Simulator modification 
flow. 


9. Determine that the MR is approved 
for implementation, but that new impact on 
GFE or CFE hardware is required for the 
the next SCP meeting. 

The SCP consists of representatives 
from the appropriate MSC directorate, from 
the NASA simulator support contractor 
project management office, and of attendees 
from other MSC organizations concerned 
with the simulator interface areas to be 
discussed. The SCP receives and reviews 
those modifications recommended for ap- 
proval or disapproval at the pre-SCP meet- 
ing. Presentations are made routinely on 
these modifications. 
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The NASA simulator support contractor SCP responsibilities and participation 
are as follows: 

1. As a routine activity, evaluate for technical impact and for simulator and 
spacecraft effectivity all MR's received from NASA, received from the prime space- 
craft contractor, or self -originated (or any combination of these sources). 

2. Assure that the necessary spacecraft data are collected and reviewed to the 
extent necessary for impact on the modification for the SCP. This impact entails the 
following activities: 

a. Estimate the engineering effort and schedule for each individual modifica- 
tion submitted for approval. This estimate includes the engineering effort necessary 
to change or update (or both) the affected hardware drawings, software mathematical 
models, specifications, interface control documents, and so forth. 

b. Estimate the programing effort and schedule for implementation of each 
software modification to the actual simulator program. The estimate will cover adding 
the modification either as a patch (octal correction) or as a basic change to the software 
load (assembly change). 

c. Estimate the design and drafting effort necessary to originate or update 
(or both) drawings, wiring lists, and other affected documents for an electrical or 
mechanical modification. This activity usually is related to the supporting engineering 
activity in item a. 

d. Estimate the on-line man-hours and machine -hours required for installa- 
tion and checkout of each modification. 

e. Estimate any required parts cost and indicate the parts sources. 

f. Estimate a final date for each modification to be ready for NASA accept- 
ance and subsequent shipment to other simulators, as required. 

3. Provide logistics support and necessary SCP documentation (agenda, minutes, 
manpower curves, etc. ) as a routine requirement. 

4. Be prepared to participate at the project managerial level in any discussions 
and reviews of the overall modification activity as it affects crew training, schedules, 
manpower levels, areas of required additional technical emphasis, and future goals for 
all simulators. 

5. Understand and implement the ECP decisions and assigned action items with 
proper NASA coordination. 
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Configuration Accountability 

Configuration accountability involves the establishment, monitoring, and updating 
of simulator documentation to define a baseline and a modified current configuration of 
a simulator at any point in time in terms of hardware and software. This process re- 
quires the following: 

1. A description and understanding of the types of documentation and the method- 
ology in changing these documents 

2. A centralized, organized, rapid -information -transfer system for implementing 
item 1 with proper interfacing approval points within configuration control management 

3. A rigorous library and information system designed to handle listings and 
records of multiple simulator configurations that are in work 

4. Standardization of items 1 to 3 

All simulator hardware has required and will continue to require comprehensive 
documentation. This documentation ranges from the basic drawing tree definition to the 
specific drawings defining fabricated and purchased hardware as well as locating the 
hardware within the simulator complex. However, within this large mass of documen- 
tation, the basic requirements and procedures for updating, providing traceability, and, 
in general, accountability are the same for every hardware document in the system. 
Thus, for purposes of this paper, discussion will be provided for a single piece of hard- 
ware documentation entitled a drawing, with the realization that, although this drawing 
may have dozens of variations and specific uses, for purposes of configuration manage- 
ment it is one homogeneous entity. 

The following facts have been proved true for hardware accountability: 

1 . A baseline set of drawings and drawing tree must be established to match sim- 
ulator hardware. 

2. One piece of paper must be generated for every simulator hardware change. 
(This paper has had and may use any one of a number of names, but it is most univer- 
sally known as an EO. ) 

3. An EO must describe before and after conditions when the EO makes a hard- 
ware change in an existing drawing. 

4. New drawings must be authorized by EO's. The EO's place the new drawings 
in their respective positions within the drawing tree by making proper references to 
the next higher and lower drawings in the tree. 

5. An EO must be approved by configuration control management and may be 
issued only to correct an error or discrepancy or to implement an approved modifica- 
tion. The only exception to this rule is the temporary EO that is used to allow experi- 
mental or short-lived changes in hardware for a definite period of time . At the 
termination of this period, the hardware must be returned to the original configuration, 
or formal modification procedures must be exercised to produce a permanent EO. 
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6. The quality control section performs the final acceptance inspection of an 
EO by comparing it to the affected, parent, and updated drawings and to the hardware. 

7. The EO's may be allowed to build up against a drawing but never to the extent 
that the usefulness of the drawing is destroyed. 

8. Each time a drawing is called for by anyone, open EO's are automatically 
provided with the requested drawing. 

9. When a drawing is modified by an EO, the modification is indicated by a re- 
vision letter on the drawing. 

10. The exact hardware configuration of any simulator can be tracked and iden- 
tified by tracking all EO's with the baseline drawings (item 1). 

11. Maximum utilization is made of computerized monitoring (particularly in 
multiple simulator and multiple configuration situations) of the hardware drawings and 
EO definitions of each individual simulator configuration. 

Although software accountability appears to be vastly different from hardware con- 
figuration activities at first sight, parallel procedures are used to focus upon the same 
goals. The Apollo Program provided the most complex simulator software control and 
accountability situation known to date and at its peak had three CM simulators and two 
LM simulators, each in different spacecraft configurations, concurrently undergoing 
some common and some unique spacecraft modifications. Coupled to this activity was 
the routine software housekeeping-discrepancy cleanup, which resulted in further im- 
pact on the situation. Fortunately, very early in the Apollo Program the master load 
concept was organized and executed, and it represents the present state of the art in 
simulator software accountability. The master load operation, the use of which has 
made the described situation workable, is summarized as follows: 

1. As was the case in hardware accountability, the first order of business is the 
establishment of one software program that operates on all common simulators with 
defining mathematical model and program -listing documentation. 

2. From item 2 forward, no change is made to the assembly, or master load, 
without a software change request (SCR) — the authorizing software configuration change 
document. 

3. An SCR may be generated only to implement a modification or to correct a 
discrepancy in the software. The SCR's are reviewed and approved by one centralized 
group before being coded for use. A temporary SCR is used with the same ground rules 
and restrictions as the temporary EO. 

4. Under normal circumstances, no newly added, revised, or corrected software 
is made directly in the assembly. 

5. Routinely, all software changes or additions (modifications of discrepancy cor- 
rections) are approved first as a patch to the existing load by all parties concerned. 
Specifically, the new work is verified as a parallel piece of software by exiting and 
entering the existing load at appropriate points. Thus, the load software represents a 
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fail-safe capability that prevents the affected program or subroutine from degenerating 
to a state any less desirable than that prevailing before a modification. 

6. Item 5 may be implemented by card patches or octal tape techniques, which- 
ever is easier for the particular simulator or rate -of -change traffic. 

7. All approved modification and discrepancy patches (SCR's) are recorded and 
approved for the next scheduled assembly. It is highly desirable to minimize this re- 
cording effort by automating (computerizing) the off-line capability to do so. (At the 
time of this writing, this activity is in work for the Apollo Program simulators. ) 

8. The frequency of new loads or assemblies is dictated by the quantity of ap- 
proved patches and the associated core and timing penalties. During the Apollo Pro- 
gram, new assemblies were generated every 3 to 4 months. 

9. Software mathematical models are updated and referenced to approved SCR’s 
by using the same logic and requirements used for the hardware drawing and the asso- 
ciated EO. The SCR is the software change -defining document. 

IQ. When a software mathematical model is called for, all open approved SCR's 
are provided automatically. 

11. Traceability exists between SCR's, patch (listing), controlling paperwork 
(discrepancy report or modification), and, if approved, the SCR occupation in the next 
new load. 


12. The octal training tape technique also should be examined for usefulness and 
application to a specific simulator program. This approach uses two octal tapes, one 
containing all newly created work and the other containing all newly approved work. 
Work is shifted (approved) from one tape to the other and, for crew training, the load 
and the octal tape with approved software are used. Naturally, the next new assembly 
adds to this approved software and the cycle repeats itself. The advantage of this oper- 
ation is that new software work can be used almost immediately without waiting for a 
new assembly. At the same time, approved software is segregated from developmental 
or unapproved software and preserves the configuration and operational integrity of the 
simulator. 


Concluding Remarks 

Because of the continuing changes of both the spacecraft and mission, and the 
necessity for a correspondingly prompt and accurate method of updating the flight crew 
simulators, a systematic method of simulator configuration management is a confirmed 
requirement. The Apollo Program provided the most severe requirements and prob- 
lems encountered to date in this area. These requirements and problems were satis- 
factorily met and resolved. The viable methods of simulator configuration management 
that were developed and refined during the Apollo Program should lend themselves di- 
rectly to future programs. 
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CONCLUSIONS 


Because of the total-commitment and economic aspects of manned space flight, 
the use of comprehensive, high-fidelity simulators for flight crew training will continue 
as a firm requirement in future programs. Through space -flight experience and the 
development of simulators to meet the training requirements, a number of factors have 
been established as basic in providing the required simulation fidelity. 

1. A high degree of crew-station detail, particularly in the full-mission simula- 
tors, is necessary to simulate accurately the spacecraft performance and mission char- 
acteristics. In addition to a complete simulation of the spacecraft controls and displays, 
such items as stowage provisions, lighting, aural cues, and crew-station hardware are 
extremely important in providing this required fidelity. 

2. Visual display systems providing out-the -window simulation of visual tasks are 
mandatory for accurate flight simulation. 

3. Moving-base simulators add a necessary degree of realism in certain phases 
of spacecraft simulation that is important to the total training requirements. 

4. A systematic method of simulator configuration management is a necessity. 
Acquiring and verifying the spacecraft and mission data, reviewing changes for appli- 
cability to the simulators, and identifying simulator configuration at any point in time 
by correlation with the spacecraft and mission are all necessary parts of this system. 
The viable methods of simulator configuration management that were developed and re- 
fined during the Apollo Program should lend themselves directly to future programs. 


Manned Spacecraft Center 

National Aeronautics and Space Administration 
Houston, Texas, July 14, 1972 
076-00-00-00-72 
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APPENDIX 

SIMULATOR DESCRIPTION 
PROJECT MERCURY 


Mercury Procedures Simulator 

Two MPS’s (fig. 1), one housed at Langley Field, Virginia, and the other in the 
Mercury Control Center at KSC, were the main crew simulators for Project Mercury. 
Both simulators used small, although somewhat different, analog computers to drive 
the equations- of -motion simulations. All spacecraft systems were simulated actively 
by hardwired electronic circuitry with the capability of introducing approximately 
276 separate system failures. The simulator at Langley Field had an active periscope 
display consisting of a moving dot (on the face of a CRT), which was activated by a hand 
controller through the analog computer. Late in the program, an out-the-window dis- 
play was added to this simulator. 


Centrifuge 

The centrifuge located at the Naval Air Development Center, Johnsville, Pennsyl- 
vania (fig. 18), was used to provide the Project Mercury crews with training for the 
launch, launch abort, and entry phases under simulated acceleration loads. The accel- 
eration simulation was mechanized in both closed- and open-loop modes through the 
Aviation Computer Laboratory analog computers. Initial runs were made in the closed- 
loop mode, in which the resulting acceleration profile as well as the panel displays 
responded to inputs from the pilot's hand controller. Analyses of these first runs indi- 
cated that adequate training could be obtained by simply preprograming the acceleration 
, profiles (open loop) . In subsequent centrifuge training, only the displays were integra- 
ted with the computer to respond to the pilot's inputs. The cockpit equipment included 
individual crew couches, restraint systems, the spacecraft hand controller, and a por- 
I tion of the spacecraft instrument panel with emphasis on the sequence telelights. 

Training was accomplished with both soft and hard pressure-suit operations. Manual 
control of the spacecraft, including manual retrofire maneuvers and simulated system 
failures during launch and entry, was covered in the training. 


Air-Lubricated Free-Attitude Trainer 

The ALFA simulator (fig. 12) was a moving-base device consisting of a Mercury- 
type couch supported by a 5-inch-diameter spherical air bearing to provide a close sim- 
ulation of spacecraft rotational motions. No computer was used; rather, the simulator 
was a direct analog of the spacecraft using compressed air jets as the attitude 
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reaction-control forces. For the cockpit displays, actual spacecraft hardware was 
used to measure the attitudes and rates and to display these values to the pilot. A sim- 
ulated out-the-window display was provided. (A detailed description is provided in the 
section entitled "Moving- Base Simulations. ") 


Part-Task Simulators 



Two part-task simulators (fig. 24) provided the first simulation of the astronaut's 
control tasks in Project Mercury. Both simulators used analog computers. The tasks 
simulated included changing spacecraft attitude in orbital flight (including orientation 

for retrofire), holding retrofire attitude in 
the presence of retrorocket misalinements, 
and damping pitch and yaw oscillations 
through the entry. 


GEMINI PROGRAM 


Gemini Mission Simulators 


Two GMS's (fig. 2) were the principal 
crew-training devices for the Gemini Pro- 
gram. One was located at MSC in Houston 
and the other at KSC. The GMS provided 
simulation of the Gemini spacecraft, the 
Gemini launch vehicle, the ground tracking 
sites, and the Agena target vehicle. The 
GMS could be operated as an independent 
crew simulator or integrated with the MCC 
for combined flight crew and flight controller 
training. The simulator included a high- 
fidelity representation of the interior of the 
spacecraft crew station, an instructor's con- 
sole with a capability to insert more than 

600 different system malfunctions, and a computer complex consisting of three digital 
computers. Infinity optical display systems were used to provide dynamic out-the- 
window scenes including the moving earth, stars, and Agena target vehicle. 


Figure 24. - Mercury part-task trainer. 


Dynamic Crew Procedures Simulator 

This moving-base simulator (fig. 21), located at MSC, provided Gemini mission 
training in the launch, launch abort, and entry phases. The gondola was supported in 
a set of gimbals that accommodated a Gemini crew station. The gimbals were driven 
in conjunction with a visual display to provide rotational cues and initial g-force onset 
typical of launch vehicle lift-off. In addition, the launch-phase environment was closely 
simulated by providing launch vehicle noise and vibrations. The DCPS was driven by a 
hybrid setup consisting of a digital computer and an analog computer. 
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Translation and Docking Simulator 

The TDS (fig. 20) was designed to provide crew training for the last 100 feet of the 
orbital rendezvous — the final closure and docking. The simulator provided six de- 
grees of freedom with the proper combination of motion of the crew station (spacecraft 
mockup) and the simulated Agena target vehicle. Both the spacecraft carriage and the 
target vehicle were supported on air bearings to provide the low friction required to 
simulate the small, precise motion of orbital flight. Various lighting conditions and 
control modes were provided in the training operation. In addition to the docking ma- 
neuver, the simulator provided a training capability for formation flying and target- 
vehicle inspection. The simulator was driven by analog computers. 


Centrifuge 

The Naval Air Development Center centrifuge (fig. 18) at Johnsville, Pennsyl- 
vania, was used to provide launch, launch abort, and entry acceleration training for the 
Gemini astronauts. The cockpit was configured to simulate the Gemini command pilot's 
station. The acceleration profiles were preprogramed; however, the entry dynamics 
as displayed to the pilot on his cockpit instruments were closed loop with the analog 
computer. Suited rims were made to include the effect on the control task of both soft 
and hard (pressurized) modes of suit operation. 


APOLLO PROGRAM 


Command Module Simulator 

Three CMS's (fig. 3), one located at MSC and two at KSC, provided the major 
portion of the CSM crew training for the Apollo Program. The three simulators were 
designed and maintained to be identical for maximum modification and operation effi- 
ciency. The CMS was capable of accurately simulating all phases of the CSM operation. 
Each CMS consisted of a high-fidelity representation of the spacecraft interior, an 
accurate presentation of exterior visual scenes through an infinity optics display sys- 
tem, an operator console, and a computer complex. The computer complex consisted 
of four digital computers, one of which was assigned solely to simulation of the onboard 
guidance computer. The CMS could be operated independently, integrated with either 
the MCC or the LMS, or integrated with the MCC and the LMS in a complete mission 
simulation mode. Beginning with training for the Apollo 10 mission, a fifth computer 
was added to each CMS to provide a simulation of the Apollo/Saturn V launch vehicle. 

Lunar Module Simulator 

Two LMS's (fig. 4), one located at MSC and the other at KSC, provided the train- 
ing for the LM portion of the Apollo missions. The two simulators were designed, built, 
and maintained to be identical. They consisted of an instructor and operator control 
console, an infinity optics display system for complete out-the-window scene simulation, 
a high-fidelity representation of the LM crew station, and a three-machine digital com- 
puter complex. The digital computers were the same as those used in the CMS. Also 
as in the CMS, one computer was assigned exclusively to simulation of the onboard 
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guidance computer. A significant portion of the LMS, which provided training for final 
touchdown, was the L&A visual display system. This system included a lunar terrain 
model (scale 1:2000) of the specific landing site for each mission. 


Command Module Procedures Simulator 

The CMPS (fig. 6) was developed originally from the GEMS and was used exten- 
sively for procedures development and verification in addition to providing crew training 
in the various flight modes. This simulator, along with the LMPS, was driven by a 
large second generation digital computer. The CMPS included the CSM guidance, navi- 
gation, and control system; the stabilization and control system; and the propulsion sys- 
tem, in addition to the guidance computer functions that were required to perform the 
rendezvous maneuvers and earth entry. An out-the-window scene, which included stars, 
the earth, and a target model, was provided through an infinity optics system. 


Lunar Module Procedures Simulator 

The LMPS (fig. 7) was operated in conjunction with the CMPS and was driven by 
the same computer system. Also like the CMPS, the LMPS was capable of simulating 
all the LM guidance and control systems, and all appropriate controls and displays. 
The visual display system used infinity optics to provide horizon and surface features, 
stars, and the CM target. 


Dynamic Crew Procedures Simulator 

The DCPS (fig. 9) for the Apollo Program training was modified by replacing the 
Gemini Program configured gondola with a CM crew station. In addition to providing 
launch, launch abort, and entry training, the simulation was expanded to cover the 
translunar injection maneuver, including the manual backup mode during this phase. 

The increased complexity of the Apollo Program required the addition of another digital 
computer to the existing hybrid setup used during the Gemini Program. 


Translation and Docking Simulator 

At the conclusion of the Gemini Program, the TDS (fig. 8) was modified to provide 
training for the Apollo LM-active docking. The LM-active mode (rather than CM- 
active) was simulated as it represented the more difficult task because of the range of 
control available, and docking was conducted with the view through the overhead window 
of the LM. An LM crew station was installed as the active vehicle, and a modified CSM 
mockup replaced the Gemini Agena as the passive target vehicle. For the initial Apollo 
flights, training for the CM-active mode was provided on the NASA Langley Research 
Center full-scale rendezvous docking simulator (RDS) (fig. 19). For later missions, 
the docking model system in the mission simulators was improved to a level that enabled 
discontinuation of training on both the TDS and the RDS. 
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Centrifuge 

The MSC centrifuge (fig. 25) was 
used to provide Apollo Program crew train- 
ing in the use of the entry monitor system 
during simulated lunar-return entry and 
associated acceleration conditions. The 
simulated cockpit in the gondola included 
three crew couches, an entry monitor sys- 
tem, a flight director attitude indicator, a 
gravity meter, and the right-hand rotational 
hand controller. Five computers, three 
analog and two digital, were used to simu- 
late the vehicle dynamics and to drive the 
centrifuge. 



Figure 25. - Centrifuge (Manned Space 
craft Center). 


Lunar Landing Training Vehicle 

The free-flight LLTV (fig. 5) was designed to provide Apollo Program crews ex- 
perience in the handling characteristics of the LM during the final portion of the lunar 
descent and touchdown. The LLTV used a vertically mounted, gimbaled jet engine, 
automatically controlled to support five-sixths of the vehicle weight. The remaining 
one-sixth was lifted by two 500-pound maximum thrust, throttleable lift rockets to sim- 
ulate the LM descent engine. The cockpit included an LM three-axis attitude control 
assembly, the throttle for the lift rockets, a horizontal velocity indicator, the altitude 
and altitude-rate tape indicators, and a thrust-to-weight indicator. Although the pilot 
of the LLTV was seated because of the necessity for a rocket -propelled ejection seat, 
the location of the flight instruments and controls relative to the pilot's hands and eyes 
was similar to that in the LM. 


Lunar Landing Training Vehicle Simulator 

The fixed-base LLTV simulator (fig. 22) was built and located at MSC to provide 
flight-crew familiarization with the LLTV systems, procedures, flight trajectories, 
and control system characteristics. The major systems that w 7 ere simulated included 
jet engine, rocket propulsion, electrical, electronic control, and jet-engine attitude 
control. The equations of motion were programed on two analog computers. A visual 
system was used for display of a simulated runway scene. 


Lunar Landing Research Facility 

The lunar landing research facility (LLRF) (fig. 16) was a research device (loca- 
ted at Langley Research Center) that was used to provide initial training. The LLRF 
used a cable tether system to support five- sixths of the crew- station weight and a hydro- 
gen peroxide system for attitude control. 
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Partial -Gravity Simulators 

Two dynamic simulators were designed and operated to provide astronaut training 
for the 1/6-g lunar-surface operations. Both simulators incorporated a uniquely de- 
signed overhead support system, which provided lifting force equal to five-sixths of the 
astronaut's total weight (suit, backpack, etc.). The vertical servosystem of the partial- 
gravity simulator (fig. 14) was suspended from an overhead monorail. This concept 
was subsequently adapted to a truck body for the mobile partial-gravity simulator 
(fig. 15) and thereby provided essentially unlimited fore-and-aft mobility. 
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